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
{{ message }}
Repository navigation
Commit a1748e5
Browse filesBrowse the repository at this point in the historyBrowse files
feat(mothership): answer a workflow tool's run still running past the worker's wait
A run_workflow* call held the turn until its run settled, up to the execution
limit, while a synchronous workflows run can already detach after
--wait-timeout (#9464). Sim now declares workflow-tool-wait-timeout and honors
the waitTimeoutMs a workflow tool frame names (synced from the mothership
contract):
- Server-run call: the handler gives the run its execution id up front and,
once the wait passes, answers {status: running, executionId, workflowId}.
The run goes on in-process; the tool execution keeps holding it, so its
lease and a Stop through the call's abort signal still reach it.
- Browser-run call: once the wait passes and a browser holds the call's
execution claim, the call is settled background, the detach a browser sends
on pagehide. The browser's run goes on, still bound to the call, so a Stop
cancels it.
- A background workflow completion now carries status: running beside its
ids, the shape the worker waits on.
A frame without waitTimeoutMs, or one with a malformed value, holds the call
as before.
0 commit comments