2adf6e08cd
When a session's PR has reached a terminal state (merged or closed) and
the session is later restored, two things conspire to attach the session
to an unrelated PR:
1. The original head branch is typically deleted on merge, so on
workspace restore `session.branch` may drift to the project default
branch (or be rewritten by an agent-side `git checkout main`).
2. With branch == default branch, downstream `detectPR` matches
whatever PR happens to share that head ref name (including fork PRs).
Fix 1 (scm-github) and Fix 2 (lifecycle) defend in depth, but the cleanest
guarantee is to refuse the restore up-front: a session whose PR has
already merged/closed has no remaining work to do. If the user wants
follow-up work, they should spawn a new session.
The previous behavior — silently clearing terminal `lifecycle.pr.*`
fields on restore and resetting `session.state` to "working" — is removed
because it's now unreachable: the new check at step 3a throws before
we get there.
Invariants preserved:
- Workers with `pr.state` of "open"/"none" still restore normally.
- `isRestorable` semantics unchanged for terminated/done/runtime-lost.
- Errors surface via `SessionNotRestorableError`, the same channel used
by other restore-blockers (workspace missing, OpenCode mapping, etc).
Refs #1724.
|
||
|---|---|---|
| .. | ||
| ao | ||
| cli | ||
| core | ||
| integration-tests | ||
| plugins | ||
| web | ||