feat(engine): summarize the active rented-loop fleet for internal ops - #6130
Conversation
No dashboards or alerts exist for the internal ops team to monitor active rented loops (JSONbored#4808). Its acceptance criterion is that an operator can see every currently active rented loop and its status at a glance. Add that view's pure decision core: buildActiveLoopFleetSummary takes the fleet as ops currently knows it and returns how many loops are live, how they break down by run status and health tier, and which ones need a human right now -- what a dashboard panel renders and what an alert rule fires on, computed once, the same way, for both. It reuses loop-escalation.ts's (JSONbored#4806) already-merged vocabulary instead of restating it, and calls evaluateEscalation itself per loop rather than re-deciding what "needs a human" means. So the fleet view and the per-loop escalation path cannot drift apart: there is one rule, called once per loop, not a second copy. A test asserts each row's decision IS evaluateEscalation's own output for that loop. Summarizes only: no dashboard, no alert delivery, no IO, no clock read. Wiring panels and alert rules into the self-host observability stack is the integration this issue is blocked on (JSONbored#4793), so this core has no opinion about Grafana or Alertmanager and stays correct whatever renders it. Invariants an operator's view must not get wrong, all tested: every status/tier key is always present (0 when none) so a panel never renders a hole; ordering is worst-severity-first with loopId as a deterministic tie-break, so a watched panel never reshuffles between renders and input order cannot change the output; the caller's array is never mutated; and a loop with no computed health tier reads as "unknown" rather than being assumed healthy -- an operator must be able to tell "nothing is wrong" from "nothing has checked yet". Closes JSONbored#4808
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6130 +/- ##
=======================================
Coverage 95.32% 95.32%
=======================================
Files 596 597 +1
Lines 47117 47133 +16
Branches 15024 15026 +2
=======================================
+ Hits 44914 44930 +16
Misses 1477 1477
Partials 726 726
Flags with carried forward coverage won't be shown. Click here to find out more.
|
loopover-orb
Bot
added
the
gittensor:feature
|
Tip 🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩 ✅ LoopOver review result - approve/merge recommendedReview updated: 2026-07-15 11:54:42 UTC
✅ Suggested Action - Approve/Merge
Review summary Nits — 4 non-blocking
Linked issue satisfactionPartially addressed Review context
Contributor next steps
Signal definitions
🧪 Chat with LoopOverAsk LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.
Full command reference: https://gittensory.aethereal.dev/docs/loopover-commands 🧪 Experimental — new and may change. 🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.
|
![loopover-orb[bot]](https://avatars.githubusercontent.com/in/4139483?s=60&v=4){kind=small}
1 participant
Summary
Closes #4808
No dashboards or alerts exist for the internal ops team to monitor active rented loops. The issue's acceptance criterion is that an internal operator can see every currently active rented loop and its status at a glance.
This adds that view's pure decision core.
buildActiveLoopFleetSummary(loops)takes the fleet as ops currently knows it and returns:activeCount— loops still running, the number an operator reads first (plustotalCountfor the whole set).byStatus/byHealth— the breakdown by run status and health tier.needingAttention— the loops misbehaving badly enough to need a human right now, worst-severity first.loops— every loop, in a stable order.That is what a dashboard panel renders and what an alert rule fires on, computed once, the same way, for both.
It reuses the escalation path rather than restating it. The vocabulary (
LoopRunOutcome,LoopHealthTier) is loop-escalation.ts's (#4806) already-merged types, andneedsAttentionis not a second opinion — each row's flag isevaluateEscalation's ownshouldEscalatefor that loop. So the fleet view and the per-loop escalation path can never disagree about what "needs a human" means: one rule, called once per loop, not a second copy that drifts. A test assertsrow.escalationequalsevaluateEscalation(facts)exactly.Scope — what this deliberately does not do
It summarizes only: no dashboard, no alert delivery, no IO, no clock read. Wiring panels and alert rules into the self-host observability stack is the integration this issue is blocked on #4793, so this core carries no opinion about Grafana or Alertmanager and stays correct whatever renders it. This is the same pure-decision-core shape the sibling Rent-a-Loop issues merged as (#4801, #4800, #4806, #4796, #4792).
feat(engine): …).CONTRIBUTING.md; nosite//CNAME/lovable; no changelog edit.Validation
git diff --checkclean.npm run build:miner— exit 0 (the engine package compiles + emits).npm run typecheck— exit 0.npx vitest run test/unit/loop-fleet-summary.test.ts test/unit/loop-escalation.test.ts— 19 tests passed (the sibling suite is included to prove the reused rule still holds).packages/loopover-engine/src/loop-fleet-summary.ts(in Codecov'scoverage.include): 100% statements (17/17), 100% branch (4/4), 100% functions (6/6), 100% lines (15/15).main.Invariants an operator's view must not get wrong — each tested:
0when none)loopIdas tie-breakunknown, neverhealthyevaluateEscalation'sSafety
Date.now(), so it is deterministic and trivially testable.