Record TUI repair notices#345
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 44 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR adds a new repair-notice module ( ChangesDashboard repair notice recording
Estimated code review effort: 3 (Moderate) | ~30 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (3)
src/multiplexer/repair-notices.test.ts (1)
5-28: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winTest coverage only exercises the non-flash branch.
The flash-enabled path (
host.modeundefined or"dashboard", settingfooterFlash/footerFlashTicks/callingrenderCurrentDashboardView) and the 20-entry ring bound are untested here. Given this module is now wired into two recovery flows, covering the flash branch and the bounding behavior would guard against regressions.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/multiplexer/repair-notices.test.ts` around lines 5 - 28, Add tests for the flash-enabled path in recordDashboardRepairNotice by covering hosts in dashboard mode and with no mode so footerFlash, footerFlashTicks, and renderCurrentDashboardView are asserted, and add a case that records more than 20 notices to verify the ring buffer behavior. Keep the existing non-dashboard assertion, but expand repair-notices.test.ts to exercise both branches and the bounded dashboardRepairNotices collection.src/multiplexer/tui-api-runtime.ts (1)
524-533: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win"waiting" notices aren't rate-limited, unlike the new blocked-notice throttle in
dashboard-control.ts.Every scheduled recovery attempt during a sustained outage records a
"waiting"notice (defaultflash: true), which both flashes the footer and appends to the bounded 20-entrydashboardRepairNoticesring on each retry cycle. This can quickly evict earlier, more informative entries (e.g. the initial"started"notice) and repeatedly re-flash the footer for the duration of an outage.dashboard-control.tsalready introducedruntimeGuardRepairBlockedNoticeReadyto rate-limit a similar repeated-notice scenario; applying an analogous throttle here would keep the notice ring and footer flashing meaningful during prolonged reconnect loops.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/multiplexer/tui-api-runtime.ts` around lines 524 - 533, The repeated "waiting" notice in the recovery path is not throttled, so each reconnect loop keeps flashing the footer and pushing older entries out of the dashboardRepairNotices ring. Add a rate-limit similar to dashboard-control.ts’s runtimeGuardRepairBlockedNoticeReady around the recovery branch in tui-api-runtime.ts, and gate the recordDashboardRepairNotice call for the "waiting" phase so it only emits periodically during a sustained outage while preserving the existing recovery state updates on host.tuiApiRecoveryPending.src/multiplexer/repair-notices.ts (1)
24-45: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider a typed host interface instead of
any.
recordDashboardRepairNoticeacceptshost: any, so typos ondashboardRepairNotices,footerFlash,footerFlashTicks, orrenderCurrentDashboardViewwon't be caught at compile time, even though the primary caller (dashboard-control.ts) otherwise uses a well-typedDashboardControlHost.♻️ Proposed typed host interface
+interface RepairNoticeHost { + mode?: string; + dashboardRepairNotices?: DashboardRepairNotice[]; + footerFlash?: string; + footerFlashTicks?: number; + renderCurrentDashboardView?: () => void; +} + export function recordDashboardRepairNotice( - host: any, + host: RepairNoticeHost, notice: Omit<DashboardRepairNotice, "at" | "error"> & { error?: unknown }, opts: RepairNoticeOptions = {}, ): DashboardRepairNotice {🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/multiplexer/repair-notices.ts` around lines 24 - 45, Replace the `host: any` parameter in `recordDashboardRepairNotice` with a typed host interface so accesses like `dashboardRepairNotices`, `footerFlash`, `footerFlashTicks`, and `renderCurrentDashboardView` are type-checked. Define or reuse a `DashboardControlHost`-style interface that includes these fields/methods, then update `recordDashboardRepairNotice` to accept that type instead of `any`. Make sure the primary caller in `dashboard-control.ts` continues to satisfy the new host type.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/multiplexer/repair-notices.test.ts`:
- Around line 5-28: Add tests for the flash-enabled path in
recordDashboardRepairNotice by covering hosts in dashboard mode and with no mode
so footerFlash, footerFlashTicks, and renderCurrentDashboardView are asserted,
and add a case that records more than 20 notices to verify the ring buffer
behavior. Keep the existing non-dashboard assertion, but expand
repair-notices.test.ts to exercise both branches and the bounded
dashboardRepairNotices collection.
In `@src/multiplexer/repair-notices.ts`:
- Around line 24-45: Replace the `host: any` parameter in
`recordDashboardRepairNotice` with a typed host interface so accesses like
`dashboardRepairNotices`, `footerFlash`, `footerFlashTicks`, and
`renderCurrentDashboardView` are type-checked. Define or reuse a
`DashboardControlHost`-style interface that includes these fields/methods, then
update `recordDashboardRepairNotice` to accept that type instead of `any`. Make
sure the primary caller in `dashboard-control.ts` continues to satisfy the new
host type.
In `@src/multiplexer/tui-api-runtime.ts`:
- Around line 524-533: The repeated "waiting" notice in the recovery path is not
throttled, so each reconnect loop keeps flashing the footer and pushing older
entries out of the dashboardRepairNotices ring. Add a rate-limit similar to
dashboard-control.ts’s runtimeGuardRepairBlockedNoticeReady around the recovery
branch in tui-api-runtime.ts, and gate the recordDashboardRepairNotice call for
the "waiting" phase so it only emits periodically during a sustained outage
while preserving the existing recovery state updates on
host.tuiApiRecoveryPending.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 1151ae51-4a32-4efc-bfed-3ba8019f6115
📒 Files selected for processing (7)
docs/north-star-completion-tracker.mdsrc/multiplexer/dashboard-control.test.tssrc/multiplexer/dashboard-control.tssrc/multiplexer/repair-notices.test.tssrc/multiplexer/repair-notices.tssrc/multiplexer/tui-api-runtime.test.tssrc/multiplexer/tui-api-runtime.ts
1 participant
Summary
Tests
Summary by CodeRabbit