Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📜 Recent review details⏰ Context from checks skipped due to timeout of 270000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
🧰 Additional context used🧠 Learnings (4)📚 Learning: 2026-02-06T15:52:42.315ZApplied to files:
📚 Learning: 2026-03-31T02:12:43.093ZApplied to files:
📚 Learning: 2026-06-10T18:18:08.545ZApplied to files:
📚 Learning: 2026-06-10T18:18:09.253ZApplied to files:
🔇 Additional comments (2)
Summary by CodeRabbit
WalkthroughHistory preservation during model profile switches is fixed across three layers: ChangesHistory Preservation Across Profile Switches
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested labels
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
LLxprt PR Review – PR #2064Issue AlignmentIssue #2049 (profile switch stalls after failed turns): The PR directly addresses the root cause. In Evidence:
Side Effects
Code Quality
Tests and CoverageCoverage impact: Increase New tests added:
Tests are behavioral and avoid mock-theater (they test outcomes, not implementation details like specific method call counts). VerdictNeeds Work — The core fix correctly addresses the stall issue, but there is a discrepancy between the diff and actual file content at |
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-24.x-ubuntu-latest' artifact from the main CI run. |
TLDR
Fixes profile/provider switching stalls after a failed or still-active turn by snapshotting already committed chat history without waiting for the previous turn to become idle. This keeps the next model call grounded in the conversation so it continues where the user left off, while avoiding promotion of partial failed in-flight content into history.
Dive Deeper
The previous refresh path asked the existing AgentClient for history while rebuilding content generator state. For initialized chats, that history API waits for the current turn to become idle. If the prior provider call was stuck in quota retry/backoff, profile loading was blocked behind the request the user was trying to escape.
This change makes the refresh path use the initialized chat's committed history snapshot directly, skips live HistoryService reuse across the switch, and stores the committed Content array for the new client. That avoids unbounded waits and prevents late mutable state from the old chat from contaminating the new one.
Additional history-preservation fixes:
Reviewer Test Plan
Recommended validation:
npm run test --workspace @vybestack/llxprt-code-core -- src/config/config.test.ts
npm run test --workspace @vybestack/llxprt-code-agents -- src/core/MessageStreamOrchestrator.modelinfo.test.ts src/core/client.test.ts
Testing Matrix
Validated on macOS:
Linked issues / bugs
Fixes #2049