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 671f88e
Browse filesBrowse the repository at this point in the historyBrowse files
fix(copilot): put the dispatch boundary at the logging session, not the core
Review was right that entering the execution core is too early. The core
loads custom blocks, workflow state, and the environment before
`safeStart` writes a row, so a setup failure — which ran nothing and is
safely retryable — still reported a dispatched run and sent the caller
looking for it.
Move the marker to `loggingStarted`, read before the catch's own recovery
`safeStart` writes a row for the failure itself. That is the first point
blocks may have executed, so it is the honest line, and it lets
executeWorkflow go back to a plain rethrow.
The thrown value stays exactly as received, including a non-Error one:
the core's finalization guard identifies it, and three existing tests pin
that. A thrown primitive therefore carries no id, which costs nothing
today because every throw site past `safeStart` raises an Error — noted in
the code rather than papered over.
Also read the marker with `Object.hasOwn` rather than `in`, so an id
reached through a prototype chain can never disclose an unrelated run, and
cover the reserved-key branch of the disclosure guard.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments