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 b434f6d
Browse filesBrowse the repository at this point in the historyBrowse files
fix(copilot): name the dispatched run from the boundary that owns it
Review found the attempted-run id attached around the whole of
executeWorkflow, which validates workspace and billing attribution before
it can create anything. A preflight refusal therefore reported a run that
never existed, telling a caller to resolve an id with nothing behind it and
to skip a retry that was safe — the mirror of the defect this branch fixes.
Move the attachment inside executeWorkflow, at the point it enters the
execution core, which is the first moment a row may exist. Everything above
it now correctly carries nothing, and the copilot layer keeps only the
window executeWorkflow cannot see: a failure after the run already
returned, where the crossing import threw and an execution certainly
exists.
Also from review:
- Attach to any thrown object rather than only an Error, and normalize a
thrown primitive past the dispatch boundary. Restricting to Error made
the invariant silently invert for a thrown plain object — the id would
not attach, its absence would read as "nothing started", and the caller
would duplicate a real run.
- Void the disclosure when an id would take one of the record's own field
names. A valid uuid under `effect` overwrote the phase the retry decision
reads, on the same all-or-nothing terms as an unvouchable id.
- Drop `effect` from the provider model response. That path spreads every
non-output field through verbatim, so the type's claim that the
disclosure reaches the model only through the withheld-result projection
was true by accident rather than by construction.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments