Dependencies and execution

A request runs its operations one at a time, in an order from the file and its dependencies. Dynomate sends no AWS call until the full request passes validation.

See also Run a request and requests run.

Dependencies

dependsOn gives the operations that must succeed before this operation runs. Use a string or an array:

[[dynamodb.get]]
name = "Read back"
dependsOn = ["Mark reviewed", "Find recent order"]
# ...
  • Use exact operation names, not normalized names.
  • An unknown name causes DNML_UNKNOWN_DEPENDENCY. A loop causes DNML_DEPENDENCY_CYCLE. Both errors stop the request before any operation runs.
  • Add a dependency to each operation that reads the result of another operation.

In the app, add dependencies from the operation header.

Ordering

Before the run, Dynomate calculates the run order:

  1. Dynomate takes the operations in file order.
  2. Before each operation, it adds its dependencies, in dependsOn order.
  3. It adds each operation one time only.
[[dynamodb.update]]
name = "Mark reviewed"
dependsOn = "Find recent order"
# ...

[[dynamodb.scan]]
name = "Audit"
# ...

[[dynamodb.query]]
name = "Find recent order"
# ...

This file runs Find recent order, Mark reviewed, then Audit. The query moves first because the update depends on it.

File order decides only the order of operations that do not depend on each other.

Validation

Before the run, Dynomate checks a fixed copy of the request, the environments, the inputs and your saved connection settings:

  1. TOML syntax.
  2. Required keys, key types, permitted values, unknown keys and template syntax.
  3. Names, dependencies and the run order.
  4. Templates, casts and typed values that use variables, environments or inputs.
  5. Connection settings and endpoint rules.
  6. Which operations are destructive, if Dynomate knows this before the run.

An error stops all AWS calls, also for valid operations before the error. The request fails with a request-level error and no operation outcomes.

Dynomate does these checks during the run:

  • Values from earlier results, before the AWS call that uses them.
  • Authentication, permissions, and if the resources exist.
  • A local import file and its contents.

For all error codes, see Errors and diagnostics.

Error Policy

onError sets what Dynomate does after an operation fails. Set a default in [execution], and override it on an operation:

[execution]
onError = "stop"          # default for every operation

[[dynamodb.query]]
name = "Optional lookup"
onError = "continue"      # this operation's own policy
# ...
ValueIn the appAfter a failure
"continue", the default Continue independent operations Dynomate skips the operations that depend on the failed operation. The other operations run.
"stop" Stop request The request stops and fails. Dynomate skips all operations that did not start.
"ignore" Continue dependents without result Dynomate records the failure. The dependent operations run without the result of the failed operation.

Outcomes

After validation, each operation in the run order gets one outcome, also operations that did not run.

Operation Status

StatusMeaning
successThe operation completed.
failedThe operation failed, timed out or you canceled it. The outcome has an error code and a message.
skippedThe operation did not run. The outcome gives the reason.
Skip reasonCause
disabledThe operation has enabled = false.
dependency-failedA dependency failed, and its error policy is not "ignore".
dependency-skippedDynomate skipped a dependency, for any reason.
stoppedThe request stopped early because of onError = "stop", a request timeout or a cancellation.

If Dynomate skips an operation, it also skips all operations that depend on it, directly or indirectly.

Request Status

StatusWhen
successEach operation succeeded or has enabled = false.
partialThe request ran to the end, but an operation failed or has a different skip reason.
failedValidation failed, an operation with onError = "stop" failed, the request timed out, or you canceled it. A request-level error gives the cause.

The app shows outcomes in the results panel. The CLI prints them and sets its exit code from the request status.

Deadlines

Two deadlines apply. The first deadline that expires stops the work.

DeadlineKeyDefault
Operation, from its start timeoutMs on the operation 10 minutes for athena.query. 5 minutes for dynamodb.createTable and dynamodb.deleteTable. None for other operations.
Full request, from its start timeoutMs in [execution] None.
[execution]
timeoutMs = 300000        # whole request: 5 minutes

[[athena.query]]
name = "Monthly totals"
timeoutMs = 120000        # this operation: 2 minutes
# ...

A timeoutMs that you set replaces the default. A deadline includes AWS calls, pagination, retries and waits for tables or Athena queries. When a deadline expires, the operation fails with DNML_TIMEOUT.

  • An operation timeout is a usual failure. The onError of the operation applies.
  • A request timeout stops the request for all onError values. The active operation fails. Dynomate skips the operations that did not start, with stopped. The request fails with DNML_TIMEOUT.

For a time limit, set timeoutMs on operations that can take a long time: dynamodb.batchWrite, dynamodb.truncate, dynamodb.import, dynamodb.export and athena.query.

Cancellation

To stop a request, select Cancel in the app toolbar, or press Ctrl+C in the CLI. The effect is the same as a request timeout, but the error is DNML_CANCELLED. Completed operations keep their outcomes.

An operation keeps the cause that stopped it first. If a deadline expired before you cancel, the error stays DNML_TIMEOUT.

A cancellation does not undo work. Wait for the final outcome to see what completed. For Athena, clientRequestToken decides if the query stops in AWS. See Athena query ownership.

No Rollback

A request is not a transaction. After a failure, a timeout or a cancellation, completed writes stay, also earlier writes of the failed operation.

  • Batch writes give each put and delete a status, also after a timeout or a cancellation: success, failed, skipped or unknown. Dynomate did not send a skipped write. It sent an unknown write, but does not know if it completed. See dynamodb.batchWrite.
  • Imports can write some items before they stop. Read the import summary in the outcome.
  • One dynamodb.transactWrite is atomic. Different operations in a request are not.

After a failure, read the outcomes before you run the request again.