Fix TUI API recovery races#240
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
More reviews will be available in 39 minutes and 15 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?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 credits. 🚦 How do rate 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 see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThe PR adds three coordinated improvements to the runtime guard and TUI API runtime: a ChangesRuntime guard identity, repair cooldown, and out-of-order gating
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
src/multiplexer/tui-api-runtime.test.ts (1)
93-156: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winAdd a regression for late older successes rewinding the generation marker.
The current cases miss this interleaving: newer success resolves, then an older success resolves, then another older failure resolves. That would catch the high-water mark regression in
lastSuccessfulRequestGeneration.🤖 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.test.ts` around lines 93 - 156, Add a regression test in TuiApiRuntime that covers the missing interleaving where a newer request succeeds, then an older request succeeds, then an even older request fails, and verify the runtime still stays connected. Use the existing TuiApiRuntime helpers and patterns from requestJson/mutateJson/refreshJson plus getConnectionState and onRequestFailure to assert that a late older success does not rewind lastSuccessfulRequestGeneration or allow the later failure to degrade state.
🤖 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.
Inline comments:
In `@src/multiplexer/runtime-guard.ts`:
- Around line 156-158: The health-check handling in runtime-guard.ts is treating
a missing projectStateDir as a mismatch because it compares the field
unconditionally in the serviceManifest assignment block. Update the logic in the
/health response handling so serviceIdentityMismatch is only computed when
json.projectStateDir is present, using the existing
getProjectStateDirFor(projectRoot) comparison only for newer services that
include that field.
In `@src/multiplexer/tui-api-runtime.ts`:
- Line 108: Keep lastSuccessfulRequestGeneration as a high-water mark in
tui-api-runtime so it never decreases on older late successes. Update the
assignments in the request success paths (the spots around the success handling
in the affected methods) to only set this field when the new generation is
greater than the current value, preserving monotonic behavior and preventing
older failures from passing the <= gate.
---
Nitpick comments:
In `@src/multiplexer/tui-api-runtime.test.ts`:
- Around line 93-156: Add a regression test in TuiApiRuntime that covers the
missing interleaving where a newer request succeeds, then an older request
succeeds, then an even older request fails, and verify the runtime still stays
connected. Use the existing TuiApiRuntime helpers and patterns from
requestJson/mutateJson/refreshJson plus getConnectionState and onRequestFailure
to assert that a late older success does not rewind
lastSuccessfulRequestGeneration or allow the later failure to degrade state.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: bfd5aa8f-895d-45ae-885c-1ea1db86478b
📒 Files selected for processing (8)
src/multiplexer/dashboard-control.test.tssrc/multiplexer/dashboard-control.tssrc/multiplexer/dashboard-model-service.test.tssrc/multiplexer/dashboard-model.tssrc/multiplexer/runtime-guard.test.tssrc/multiplexer/runtime-guard.tssrc/multiplexer/tui-api-runtime.test.tssrc/multiplexer/tui-api-runtime.ts
| if (status >= 200 && status < 300 && json?.pid === endpoint.pid && json?.serviceInfo) { | ||
| serviceManifest = json.serviceInfo; | ||
| serviceIdentityMismatch = json.projectStateDir !== getProjectStateDirFor(projectRoot); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
rg -nP 'projectStateDir' src/metadata-server.ts src/paths.ts
ast-grep run --pattern 'send($_, 200, { $$$ })' --lang typescript src/metadata-server.tsRepository: TraderSamwise/aimux
Length of output: 14005
🏁 Script executed:
#!/bin/bash
set -euo pipefail
ast-grep outline src/multiplexer/runtime-guard.ts --view expanded
printf '\n--- runtime-guard excerpt ---\n'
sed -n '130,180p' src/multiplexer/runtime-guard.ts
printf '\n--- health response type search ---\n'
rg -n "projectStateDir|serviceInfo|/health|health" src -g'*.ts'Repository: TraderSamwise/aimux
Length of output: 50375
🏁 Script executed:
#!/bin/bash
set -euo pipefail
ast-grep outline src/multiplexer/runtime-guard.ts --view expanded
printf '\n--- runtime-guard excerpt ---\n'
sed -n '130,180p' src/multiplexer/runtime-guard.ts
printf '\n--- health response type search ---\n'
rg -n "projectStateDir|serviceInfo|/health|health" src -g'*.ts'Repository: TraderSamwise/aimux
Length of output: 50375
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- health route ---'
sed -n '1788,1812p' src/metadata-server.ts
printf '\n%s\n' '--- runtime-guard tests around projectStateDir ---'
sed -n '200,240p' src/multiplexer/runtime-guard.test.ts
printf '\n%s\n' '--- runtime-guard state handling ---'
sed -n '1,120p' src/multiplexer/runtime-guard.ts
printf '\n%s\n' '--- health contract type ---'
sed -n '280,310p' src/project-api-contract.tsRepository: TraderSamwise/aimux
Length of output: 8021
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- health route ---'
sed -n '1788,1812p' src/metadata-server.ts
printf '\n%s\n' '--- runtime-guard tests around projectStateDir ---'
sed -n '200,240p' src/multiplexer/runtime-guard.test.ts
printf '\n%s\n' '--- runtime-guard state handling ---'
sed -n '1,120p' src/multiplexer/runtime-guard.ts
printf '\n%s\n' '--- health contract type ---'
sed -n '280,310p' src/project-api-contract.tsRepository: TraderSamwise/aimux
Length of output: 8021
Guard missing projectStateDir before comparing.
/health includes this field in the current build, but older services can omit it. As written, undefined !== getProjectStateDirFor(projectRoot) turns that into a false service-mismatch; only compare when the field is present.
🤖 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/runtime-guard.ts` around lines 156 - 158, The health-check
handling in runtime-guard.ts is treating a missing projectStateDir as a mismatch
because it compares the field unconditionally in the serviceManifest assignment
block. Update the logic in the /health response handling so
serviceIdentityMismatch is only computed when json.projectStateDir is present,
using the existing getProjectStateDirFor(projectRoot) comparison only for newer
services that include that field.
1 participant
Summary
Verification
Summary by CodeRabbit