Fix/1114 health summary failure aliases#1184
Conversation
Greptile SummaryThis PR fixes a long-standing inconsistency where
Confidence Score: 4/5Not safe to merge until the unresolved merge conflict in the docs file is resolved. The core code change in docs/daily-updates/2026-04-30.mdx — unresolved merge conflict must be resolved before merging. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A["status string (raw)"] --> B[".strip().lower()"]
B --> C{"_STATUS_BUCKETS.get(status, 'other')"}
C -->|"passed / pass / ok / healthy"| D["bucket = 'passed'"]
C -->|"missing"| E["bucket = 'missing'"]
C -->|"failed / fail / error / unhealthy"| F["bucket = 'failed'"]
C -->|"warn / degraded / unknown / empty / …"| G["bucket = 'other'"]
D --> H["counts[bucket] += 1"]
E --> H
F --> H
G --> H
H --> I["return counts dict"]
Reviews (1): Last reviewed commit: "fix(cli): align health summary counts wi..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| <<<<<<< HEAD | ||
| - Fallback summary used: `yes` | ||
| ======= | ||
| - Fallback summary used: `no` | ||
| >>>>>>> ec13f462 (docs(daily-update): archive 2026-04-30) |
There was a problem hiding this comment.
This file contains raw Git conflict markers (<<<<<<<, =======, >>>>>>>). Any MDX parser or documentation build pipeline will fail or render the conflict markers literally. One of the two values — yes or no — needs to be chosen and the conflict markers removed before this file can be merged.
|
🍕 @AniketR10's PR: crispy edges, no unnecessary toppings, delivered on time. Understood the assignment. 🔥
👋 Join us on Discord - OpenSRE : hang out, contribute, or hunt for features and issues. Everyone's welcome. |
2 participants
Fixed #1114
Code Understanding and AI Usage
Did you use AI assistance (ChatGPT, Claude, Copilot, etc.) to write any part of this code?
If you used AI assistance:
Explain your implementation approach:
The bug is a consistency issue between two functions that both normalize the same input but disagree on the rules.
status_badge()already had a complete alias table for failure-like statuses (failed,fail,error,unhealthy);_summary_counts()only matched the canonical bucket name. The fix is to make both share the same normalization shape.I considered three approaches:
if/elifladder inside_summary_counts()— would work, but duplicates the alias list fromstatus_badge()and drifts the moment one of them adds a new alias._summary_counts()callstatus_badge()and key off.plain— couples a counting function to a RichTextrendering function, which feels backwards: rendering should depend on classification, not the other way around._STATUS_BUCKETSdict and let_summary_counts()look up. It's the smallest change, keeps both functions independent of each other, and makes the alias set obvious to a reader.Key pieces:
_STATUS_BUCKETS: maps every recognized status string (already lowercased/stripped at the call site) to its canonical bucket. Aliases likepass/ok/healthycollapse topassed;fail/error/unhealthycollapse tofailed._summary_counts(): unchanged signature and return shape. The body is now a singledict.get(status, "other")lookup followed by an increment, so unknown statuses still fall through tootherexactly as before.Edge cases covered by the new tests:
FAILED) - already handled by the existing.strip().lower(), asserted explicitly.other.WARN(warn,degraded) stay asotherbecause the JSON shape doesn't have awarnbucket and the issue scopes this fix to failure-state alignment.Checklist before requesting a review