DLQ

Bulk Resume Workflows from DLQ

Changed on

When a workflow run fails, it's automatically moved to the DLQ (Dead Letter Queue) where it can be analyzed and resumed. The resume feature allows you to continue a failed workflow run from exactly where it failed, without re-executing successfully completed steps.

This is particularly useful for long-running workflows where you don't want to lose progress from successful steps when a single step fails.

When a workflow is resumed, it continues execution from the last failed step. A new workflow run ID is generated, but the workflow maintains the state and results from previously completed steps.

<Note> You can make changes to the workflow code as long as these changes come after the failed steps. However, making changes before the failed step will break the code and is not allowed.
For more details, check out [Handle workflow route code changes](/workflow/howto/changes) page.
</Note>
post/v2/workflows/dlq/resume

Request

Query parameters

dlqIdsstring[]

List of specific DLQ IDs to resume. If provided, other filters are ignored.

cursorstring

Pagination cursor for resuming workflows in batches.

countinteger

Maximum number of workflows to resume. If not provided, all matching workflows will be resumed.

fromDateinteger

Filter workflows by starting date, in milliseconds (Unix timestamp). This is inclusive.

toDateinteger

Filter workflows by ending date, in milliseconds (Unix timestamp). This is inclusive.

workflowUrlstring[]

Filter workflows by workflow URL. Supports multiple values.

workflowRunIdstring

Filter workflows by workflow run ID.

workflowCreatedAtinteger

Filter workflows by creation timestamp in milliseconds (Unix timestamp).

labelstring[]

Filter workflows by label. Supports multiple values. You can pass multiple values to match workflows with any of the given labels (OR logic).

Examples:

  • label=my_label
  • label=label_1&label=label_2
  • label=label_1,label_2
failureFunctionStatestring[]

Filter workflows by failure function state. Supports multiple values.

StateDescription
CALLBACK_INPROGRESSThe failure function is in progress.
CALLBACK_SUCCESSThe failure function run successfully.
CALLBACK_FAILThe failure function failed to run.
CALLBACK_CANCELEDThe failure function was manually canceled
callerIpstring[]

Filter workflows by IP address of the publisher. Supports multiple values.

flowControlKeystring[]

Filter workflows by Flow Control Key. Supports multiple values.

Headers

Upstash-Retriesinteger

Override the number of retries for the remaining workflow steps.

Upstash-Delaystring

Override the delay before executing the next workflow step. Format is <value><unit> (e.g., "10s", "5m").

Upstash-Retry-Delaystring

Override the retry delay expression for the remaining workflow steps.

Upstash-Flow-Control-Keystring

Override the flow control key for the remaining workflow steps.

Upstash-Flow-Control-Valuestring

Override the flow control configuration in the format parallelism=<value>, rate=<value>, period=<value>.

Upstash-Labelstring

Override the label(s) for the remaining workflow steps.

You can assign multiple labels by providing a comma-separated list.

Example: label_1,label_2

Upstash-Failure-Callbackstring

Override the failure callback URL for the remaining workflow steps.

Response

Workflows resumed successfully

cursorstring

Pagination cursor to use in subsequent requests. If empty, all matching workflows have been processed.

Changes

    • info

      for the query request parameter callerIp, the type was generalized from string to array

    • info

      for the query request parameter failureFunctionState, the type was generalized from string to array

    • info

      for the query request parameter flowControlKey, the type was generalized from string to array

    • info

      for the query request parameter workflowUrl, the type was generalized from string to array

    • info

      for the query request parameter label, the type was generalized from string to array