Resume a paused plan (Enterprise only)

Resume execution of a plan that is paused at an approval gate. Used with confirm and step execution modes.

• confirm mode: Every step requires explicit approval
• step mode: First step auto-executes, subsequent steps require approval

Set approved: true to approve and execute the next step, or approved: false to reject and abort the plan.

The resume acts on the workflow bound to the plan when it entered confirm or step mode (#4249), read under the caller's tenant (the tenant that executed the plan). A plan that entered its mode before that binding existed is resumed through the workflow named for its mode under the plan's tenant, and refused when that selection is not the one live workflow.

The plan's steps run in order (#4249). The step that runs is the plan's NEXT step: the lowest-numbered step that has not run. The resume approves (approved: true) or rejects (approved: false) that step's pending gate and no other; a step already approved through the plan-level approve route runs. A later step's gate, whoever wrote it, is read only at that step's turn. In step mode the first resume runs the ungated first step, and records it before it runs (a workflow_steps row with decision allow, no approval status and the reason step_mode_first_step_ungated), so a later gate cannot make the resume skip it. A step-mode plan in flight at the upgrade to this release has that record written for it (reason backfilled_at_upgrade), at the orchestrator's start or at its next resume; until the upgrade's migration 187 has run, such a plan's resume answers 409.

A resume never runs a step past a gate that is not approved. It answers 403 when the caller is not of the plan's tenant and cannot see the plan's workflow; 404 when the caller is of the plan's tenant and the workflow is not visible to it (for example, another tenant of the organization executed the plan, or the workflow was deleted); and 409, running nothing, when:

• the plan is not in confirm or step mode;
• the plan's workflow is still being set up: it was marked executing and its executor has not returned. An executor that fails fails the plan; a plan left in this state (for example after a process stop) is ended with POST /api/v1/plan/{id}/cancel;
• the plan's workflow has ended (a rejection or an expiry aborts it); approved: false then fails the plan instead;
• the plan's next step's gate is pending (the error names the step to approve), has no approval, or was rejected or expired, or its approval is refused because it is no longer pending;
• a confirm workflow has no gate row, or no gate row names the plan's next step;
• every step of the plan has already run;
• the plan's first step is already recorded by a concurrent resume;
• (a step plan in flight at the upgrade) whether its first step ran cannot be decided yet, because migration 187 has not run;
• the pending step's approval has expired (approval_expired), as the workflow step approve answers it;
• (a plan without a binding) a workflow named for the plan has ended, or more than one is running.

It answers 503, approving and running nothing, when the approval's state cannot be read (approval_state_unreadable), as the workflow step approve answers it.

It answers 500 when a step ran but its completion could not be recorded; the step's row still reads not completed, so the next resume runs that step again (at-least-once). A step-mode first step whose record was written but whose run never finished is run by the next resume the same way.

Requires: Enterprise license.