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
refactor(copilot): decide the run phase where the caller lives, not in the executor
Ten review rounds chased the same question — when exactly may a side effect
have occurred — through six positions in the executor, ending with a
callback on every block of every execution in the product. Against 543k
executions a week, serving a disclosure read about fifty times a week. The
precision was never the point: `attempted` and `performed` both mean an
execution exists under this id, and the caller was already handed the id
that resolves it.
Revert all of it. The engine, the orchestrator, both context types and the
callback threading through execute-workflow and execution-core go back to
staging untouched; the executor's only remaining change is the id carrier
in utils/errors.ts.
The phase now comes from what the copilot layer already holds. Its `try`
opens on the executor call, so everything it catches is post-dispatch by
construction while authorization, admission and provenance export throw
past it having created nothing — no id means nothing exists, an id means
resolve it. A result in hand says how the run ended, which separates
cancelled and paused from completed.
The harness that motivated this is now in the diff: every outcome the run
path can produce, driven through the real handler and the real projection,
asserted on the retry decision a caller can reach and on no run content
crossing. Six mutations were used to confirm it fails for the right
reasons; one of them found the dispatch flag this refactor introduced was
already dead, and it is gone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 commit comments