fix(server): allow forks from provider-finished runs - #13541
Conversation
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This is a localized server bug fix that permits forks from provider-finished runs while keeping active and rolled-back runs blocked. Native versus portable fork behavior is explicitly bounded and covered by execution tests, with no schema, security, billing, deployment, or default-setting impact. You can add or adjust custom eligibility rules. Learn more. |
Thread transfer impact✅ Thread transfer remains within every enforced ceiling.
Baseline: unavailable · PR result: Scenario and decoded snapshot size10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.
Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
fe4f6ad to
87c67bd
Compare
5d4c72c to
945a40e
Compare
- Only fork natively when the source run completed or is waiting; failed, interrupted, and cancelled runs fall back to a portable transcript that stops at the selected run - Pass the source run status into decideForkExecution - Add execution tests for Codex and Claude forks of failed, interrupted, and cancelled runs
What Changed
Allow forks from completed, waiting, failed, interrupted, and cancelled runs. Keep in-progress and rolled-back runs ineligible. Update the Codex replay fixtures and recording script to match current app-server behavior.
Why
A provider-finished run can still have a usable native thread or transcript, even when it ends because of a usage limit or another failure. Restricting forks to completed runs blocked users from continuing that work in a new thread.
Checklist