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) (#3552)
* 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
* docs(api): show the screen-flow resume round-trip in the client SDK guide (#3528)
The SDK page's automation example stopped at `trigger()`, which is exactly the
gap the issue reports: a reader had no way to learn that `execute()` on a
screen flow returns a paused run, or how to finish it. Adds the
execute → paused → resume round-trip and `getScreen()` for a client that did
not launch the run.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LX9ut3MK3KykE11S9bJmv5
---------
Co-authored-by: Claude <zhuangjianguo@steedos.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
0 commit comments