Repository navigation
fix(ssh): stop expiring relay-reset leases when the force-stop threw - #17962
Conversation
A force-stop that rejected never observed the remote shells, so bulk-expiring their leases in the finally block recorded a verdict Orca does not hold. Mirror ssh:terminateSessions: only a fulfilled stop retires a lease. Local PTY handles are still cleared, so nothing is stranded — the next connect reattaches the survivors or expires them on host evidence.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 10 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe SSH relay reset flow now records whether remote relay force-stop succeeds. It expires persisted remote PTY leases only after successful force-stop completion. When force-stop fails, the error propagates, leases remain unchanged, local PTY state and ownership are cleared, and the connection disconnects. A test covers the Merge Risk: ⚪ Minimal · up to This change keeps SSH leases available for recovery when a relay stop fails, preventing live sessions from being incorrectly marked expired. The successful-reset path is unchanged, and no actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
Full details: Description checkExplanation The description explains the change, rationale, behavior, regression test, and test results. However, it omits several required template sections, including an explicit Linked Issue entry using Resolution Add the missing template sections. Provide a linked issue in the required
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
- Gate lease expiry on force-stop acknowledgment —
doResetRelaynow marks remote PTY leasesexpiredonly whenforceStopRelayForTargetfulfilled, so a thrown stop no longer records a verdict the app never obtained. - Throw-path test coverage — a new
ssh:resetRelaytest asserts leases stay alive when the force-stop rejects, while local handle cleanup, the credential-flag clear, anddisconnectstill run unconditionally.
DeepSeek Pro (free via Pullfrog for OSS) | 𝕏
…tablyai#17962) A force-stop that rejected never observed the remote shells, so bulk-expiring their leases in the finally block recorded a verdict Orca does not hold. Mirror ssh:terminateSessions: only a fulfilled stop retires a lease. Local PTY handles are still cleared, so nothing is stranded — the next connect reattaches the survivors or expires them on host evidence. Mirror-Of: 7dd2ff5
…tablyai#17962) A force-stop that rejected never observed the remote shells, so bulk-expiring their leases in the finally block recorded a verdict Orca does not hold. Mirror ssh:terminateSessions: only a fulfilled stop retires a lease. Local PTY handles are still cleared, so nothing is stranded — the next connect reattaches the survivors or expires them on host evidence.

Fixes the relay-reset path recording a verdict it never obtained. Found during the SSH bug sweep (#17817–#17957).
ELI5
ssh:resetRelaybulk-expired every lease on the target inside afinallyblock — so it fired even whenforceStopRelayForTargetthrew. A failed stop means we don't know what happened to those shells; marking their leases dead records a conclusion we never reached. Perdocs/reference/ssh-execution-boundary.md, loss of contact is never evidence of process death.Now the expire only runs when the force-stop actually fulfilled:
This copies the model already used correctly in the sibling path at
ssh-connection-handlers.ts:156, which only marksterminatedwhenprovider.shutdownfulfilled and whose comment explicitly keeps the lease alive when shutdown failed.Local handle cleanup (
clearProviderPtyState/deletePtyOwnership), the credential-flag clear, and thedisconnectall stay unconditional in thefinally— those are stale either way and record no verdict. The error still propagates to the IPC caller.Nothing is stranded by leaving the leases alone
The next connect resolves them on evidence:
ssh-relay-session.ts:2274-2276and:1982-1987both filterstate !== 'terminated' && state !== 'expired'and attempt reattach.handlePtyReattachFailureexpires them.ssh:terminateSessionsalso still reaches them.User-facing regressions
None expected. The only behavior change is on the throw path, where the previous behavior was to record a false verdict. A successful reset is unchanged.
Negative controls: the pre-existing
'ssh:resetRelay force-stops the remote relay and expires tracked leases'and'ssh:resetRelay clears scoped live PTYs while expiring raw leases'both still pass. The new test also asserts local handles are still cleared on the throw path.Old-client impact: none. Main-process only — no RPC params, stream frames, or published content changed.
Testing
New test
ssh-relay-reset-resume.test.ts→ 'ssh:resetRelay keeps leases alive when the force-stop never reported a result'.Before:
After:
Suites: 5 files / 50 tests and 3 files / 43 tests green.
tc:node,tc:webclean;check:code-quality:changed0 new findings.