You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(client): resume + getScreen on the automation SDK surface (#3528)
A `type: 'screen'` flow suspends at its `screen` node — `execute()` returns
`{ status: 'paused', runId, screen }` and the run waits for input. The
dispatcher has served the other half of that contract since ADR-0019
(`POST /automation/:flow/runs/:runId/resume`, `GET .../screen`), but the client
SDK's automation surface stopped at getFlow / execute / listRuns / getRun. Any
consumer built on the SDK could therefore start a screen flow and never finish
it: the run stayed suspended and the only way out was hand-rolling the HTTP
call. That is what dead-ended the Console's developer "Flow Runs" test runner,
where every test run of a screen flow orphaned a `paused` row.
- `automation.resume(flowName, runId, signal?)` posts the collected screen
values as `inputs`, plus the approval-style `output` / `branchLabel` the
dispatcher already accepts, and returns either the next paused screen of a
multi-step wizard or the terminal AutomationResult.
- `automation.getScreen(flowName, runId)` returns the screen a paused run is
waiting on, so a client that did not launch the run (a reload, another tab,
an inbox) can render the pending step before resuming.
- Both land on the environment-scoped client as well as the unscoped one.
The two dispatcher routes had no test coverage at all; they now cover the
`inputs` / `variables` aliasing, approval-style output + branchLabel, the
pause-again envelope, the 501 when the service cannot resume, and the ordering
guard that keeps `/runs/:runId/screen` from being swallowed by the run lookup.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LX9ut3MK3KykE11S9bJmv5
0 commit comments