Repository navigation
fix(libsy): preserve plan-execute sessions at capacity - #921
Conversation
Signed-off-by: Ryan Lempka <rlempka@nvidia.com>
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (2)
Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 11 remain after this review. WalkthroughThe router retains up to 4,096 identified executing sessions. It rejects a new mutation handoff at capacity without evicting an existing session. Final requests release existing session slots, and final handoffs do not consume a slot. ChangesSession capacity handling
Priority: ➖ Normal Estimated code review effort: 3 (Moderate) | ~15 minutes Merge Risk: ⚪ Minimal · up to Existing sessions remain routed to the efficient target at capacity, and final requests free or avoid session slots as documented. No identified issue prevents merging after normal checks. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 62.50% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 8 functions across 1 files. (1 skipped: 1 unsupported.)
A rabbit watched the sessions stay, Comment |
What
Keep active Plan/Execute sessions on the efficient model. At the 4,096-session limit, new handoffs return a capacity error (HTTP 500). Marking an existing session with
session_final: truefrees a slot so the handoff can be retried.Why
Adding a new session used to remove an existing session from memory. If compaction had removed its edit history, that session would restart planning.
Notes for reviewers
Final requests still work at capacity. Added regression tests and documented the limit.
All 339 library tests passed, along with formatting, workspace Clippy, and the strict docs build. No live provider calls were made.