fix: an unreachable host reported its containers as running - #201
Conversation
The Fleet page coloured every container chip from the status frozen into the worker's last heartbeat, with no staleness input. A host that is powered off rendered a row of success-green chips — "honeygain, traffmonetizer" — next to a machine CashPilot had not heard from in hours. The only counter-signal was a grey dot and a "Last seen" line elsewhere on the card, and green is the louder signal. renderApps had the same defect one function above; the bead named only the containers. A colour is a claim about right now, and that claim can only be made while the worker is reachable. The state is still shown, because "what was running when we last heard" is genuinely useful — it is now shown as a memory rather than a measurement: muted, dashed, headed "Last known state — not reachable", with a tooltip naming when it was last true. Proof is a node harness rather than a Python assertion, because these renderers live in a <script> block inside a Jinja template: a text assertion could only show the source mentions a variable, never what colour a given worker produces. The harness extracts the real functions and inspects their output. CI runs it as its own step, and pytest shells out to it so a local run catches it too. Negative control: colouring containers from the frozen status again fails it; the same for apps; and hiding the list instead of marking it fails a different assertion, so the lazy fix cannot pass either. Closes CashPilot-1m8
|
Warning Review limit reached
Next review available in: 24 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
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 |
1 participant
The defect
The Fleet page coloured every container chip from the status frozen into the last heartbeat, with no staleness input:
So a host that is powered off rendered a row of success-green chips — "honeygain, traffmonetizer" — next to a machine CashPilot had not heard from in hours. The only counter-signal was a grey dot and a "Last seen" line elsewhere on the card, and green is the louder signal.
renderAppshad the same defect one function above. The bead named only the containers.The fix
A colour is a claim about right now, and it can only be made while the worker is reachable.
The state is still shown — "what was running when we last heard" is genuinely useful — but as a memory rather than a measurement: muted, dashed, headed "Last known state — not reachable", with a tooltip naming when it was last true.
Evidence
Proof is a node harness, not a Python assertion, because these renderers live in a
<script>block inside a Jinja template — a text assertion could only show the source mentions a variable, never what colour a given worker actually produces. The harness extracts the real functions and inspects their output (11 assertions).CI runs it as its own step, and pytest shells out to it so a local run catches it too. A test also asserts CI invokes every browser-free harness, so a new one can't sit unrun.
Negative control:
The third matters: the obvious shortcut — just don't render the chips — fails a different assertion, so it can't pass by accident.
Controls also pin the ordinary cases: a reachable host still goes green, an exited container on a live host still reads stopped, and the app traffic tooltip survives alongside the new staleness one.
Closes CashPilot-1m8