refactor(session): extract safe recovery gate#929
Conversation
📝 WalkthroughWalkthroughThis PR centralizes replay-safety evaluation and side-effect boundary snapshot computation into dedicated modules (RunIncident and RunObservability), removing duplication and establishing a single source of truth for safety gate decisions and boundary proofing used during retry logic and stream processing. ChangesCentralized Replay Safety and Boundary Snapshot Evaluation
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related issues
Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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.
Code Review
This pull request refactors the session retry and observability logic by extracting sideEffectBoundarySnapshot into the RunObservability namespace and introducing a dedicated evaluateReplaySafety function within the RunIncident namespace. Additionally, new unit tests are added to verify these changes. The review feedback suggests simplifying imports in retry-decision.ts by removing the redundant type import and alias, and adding extra test cases to ensure full coverage of the newly extracted safety gate logic.
Summary
Extracts the safe-recovery replay gate out of retry decision assembly and moves side-effect boundary snapshot construction into run observability.
Why
This is PR 2 for #925. The retry metadata from PR 1 can now depend on a run-incident-owned safety gate instead of interpreting safe-recovery recommendations inline. The processor also stops owning the side-effect boundary proof details needed by recovery safety.
Related Issue
Closes part of #925.
Human Review Status
Approved by -Han
Review Focus
Please focus on whether
RunIncident.evaluateReplaySafetyowns only replay safety, while technical retryability, retry attempt metadata, and presentation mapping remain in retry classification / retry decision code.Risk Notes
No behavior change intended. The main risk is accidentally changing safe-recovery replay classification, especially budget exhaustion and reasoning-only replay. Platform, UI, docs, dependency, and generated-file checklist items are not applicable.
How To Verify
Screenshots or Recordings
Not applicable. No visible UI or copy changes.
Checklist
bug,enhancement,task,documentation. Type labels are author-added; the labeler bot does NOT assign them. Add the label in the GitHub UI, then tick this.app,ui,platform,harness,ci. The labeler bot assigns these on PR open based on changed paths. Confirm the bot's choice (or override if wrong), then tick this.P0,P1,P2,P3. The priority-triage bot suggests one on PR open. Confirm or override, then tick this.Pending,Approved by @<reviewer>, orNot required: <reason>(default isPending; "not required" is restricted to bot-authored low-risk PRs).dev, and my PR title and commit messages use Conventional Commits in English.