Skip to content

fix(health): fold unrecognized surface status into unknown in subnet rollups (#1739)#1961

Closed
minion1227 wants to merge 1 commit into
JSONbored:mainfrom
minion1227:minion_1739
Closed

fix(health): fold unrecognized surface status into unknown in subnet rollups (#1739)#1961
minion1227 wants to merge 1 commit into
JSONbored:mainfrom
minion1227:minion_1739

Conversation

@minion1227

Copy link
Copy Markdown
Contributor

Summary

rollupSubnetStatus — the single source of truth for a subnet's overall
status — only inspects the four ok / degraded / failed / unknown
buckets. But every status tally incremented counts[row.status] directly, so a
status outside those four landed in a stray key (e.g. counts.weird) that the
rollup never reads. A subnet whose surfaces were all unrecognized therefore
had failed === 0 && degraded === 0 and wrongly rolled up to ok — a
false-green in both the live serve overlay (summarizeRows) and the 15-minute
cron health:current snapshot (summarizeGroup), and a stray bucket leaked
into summary.status_counts.

This adds a shared tallyStatus helper that folds any unrecognized status into
unknown, and routes every status tally through it so the fold can never drift
between the prober and the serve path.

Closes #1739

What Changed

  • src/health-probe-core.mjs — new exported tallyStatus(counts, status)
    helper placed next to rollupSubnetStatus (keeping the precedence logic and
    the tally logic colocated). It increments the matching bucket and folds any
    status outside the four known ones into unknown, guarding with Object.hasOwn
    so inherited prototype keys (e.g. "constructor") are treated as unrecognized
    rather than matching via the prototype chain.
  • src/health-prober.mjs — route summarizeGroup, plus the two run-level
    diagnostic counts in runHealthProber and persistToKv, through tallyStatus.
  • src/health-serving.mjs — route summarizeRows through tallyStatus.
  • Tests — new tallyStatus unit suite (known bucket, unrecognized/undefined
    fold, "constructor" prototype-key fold); an end-to-end prober test proving an
    all-unrecognized subnet rolls up to unknown with unknown_count: 2 and no
    stray bucket in summary.status_counts; and serve-path tests for the
    all-unrecognized → unknown case plus a mixed weird + failed case proving
    the fold never masks a real failure.

Net: 6 files, +91 / −10 — small, surgical source change; the bulk is regression
coverage. No schema, OpenAPI, or generated artifacts touched.

Registry Safety

  • No secrets, PATs, wallet data, private dashboards, private URLs, or
    validator-local state.
  • Generated artifacts were produced by repo scripts, not hand-edited.
  • R2-only/high-churn detail artifacts are not committed.
  • Public API/OpenAPI/schema changes are intentional and documented. (none —
    behavioral fix only; no schema or response-shape change.)

Validation

  • npm run check
  • npm run validate
  • npm run validate:schemas
  • npm run validate:api
  • npm run validate:openapi
  • npm run validate:types
  • npm run validate:artifact-budgets
  • npm run validate:docs
  • npm run validate:intake
  • npm run validate:workflows
  • npm run worker:test
  • npm run test:coverage
  • npm run scan:public-safety
  • git diff --check

…rollups (JSONbored#1739)

rollupSubnetStatus only reads the ok/degraded/failed/unknown buckets, but the
status tallies incremented counts[row.status] directly. A status outside those
four landed in a stray key (counts.weird) that the rollup ignored, so a subnet
whose surfaces were ALL unrecognized had failed===0 && degraded===0 and wrongly
rolled up to "ok" — in both the live serve overlay (summarizeRows) and the
15-minute cron health:current snapshot (summarizeGroup).

Add a shared tallyStatus helper next to rollupSubnetStatus (the single source of
truth for status precedence) that folds any unrecognized status into unknown,
and route every status tally through it — summarizeRows, summarizeGroup, and the
two run-level diagnostic counts — so the fold can never drift between the prober
and the serve path or leak a stray bucket into summary.status_counts.

Closes JSONbored#1739
@superagent-security

Copy link
Copy Markdown

Superagent didn't find any vulnerabilities or security issues in this PR.

@JSONbored JSONbored added the banned Banned due to plagiarism or other repeat violations. label Jun 26, 2026

@JSONbored JSONbored left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Closing this, and I want to be transparent about why.

This account is permanently blocked from contributing to our repositories — for plagiarism. In JSONbored/gittensory you filed two PRs that were copies of another contributor's open work, submitted as your own to claim the credit:

Lifting another contributor's diff to claim the credit is a hard line for us — two strikes, you're out. Our Code of Conduct states it plainly: plagiarism and reward-farming result in a permanent block from contributing, enforced across JSONbored/gittensory, JSONbored/metagraphed, and JSONbored/awesome-claude.

The block is on the account, not any individual PR, so this isn't a review of the change — it's enforcement of the ban. Closed and labeled slop. This decision is final.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

banned Banned due to plagiarism or other repeat violations.

Projects

No open projects
Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants