Skip to content

update-health-badge picks the first state word on the line, not the health value #595

Description

@russmiles

update-health-badge.sh picks the health status with a case over the whole - Health: line:

case "$health_line" in
  *[Dd]egraded*)  health_status="Degraded" ;;
  *[Aa]ttention*) health_status="Attention" ;;
  *[Hh]ealthy*)   health_status="Healthy" ;;

First match wins, and the match is a substring test over the entire line. So any state word appearing anywhere on that line — in a parenthetical, a revision note, a comparison — beats the actual value.

Observed, not hypothetical

Writing the 2026-08-25 end-of-day snapshot, the Health line read:

- Health: **Attention** *(revised twice — held at Degraded at 16:00, upgraded at end of day)*

The script wrote Degraded. The word appears in the annotation explaining the previous state, and *[Dd]egraded* is tested first.

The badge was wrong in the direction that understates health, which is the safe direction — but the same defect reversed is not safe. A line reading - Health: **Degraded** *(was Healthy last month)* would produce a green badge on a degraded habitat, because *[Dd]egraded* matching first is an accident of ordering, not a safety property.

Why this keeps happening to this file

This is the second defect in this script in one day. #575 fixed an argument-less call falling through to a hardcoded Healthy. The fix made the default honest — but the matcher still answers an easier question than the one it names: "does this line contain a state word?" rather than "what is this line's value?".

That is the same shape as the three GC tools repaired in #587 and the convention-parity gate that compares headings but not values. Fourth instance in a day.

Fix

Extract the value rather than substring-matching the line:

health_status=$(printf '%s\n' "$health_line" \
  | sed -n 's/^[[:space:]]*-[[:space:]]*Health:[[:space:]]*\**\([A-Za-z]*\)\**.*/\1/p')

Then map the extracted token, and fail rather than default if it is not one of the three known values — an unrecognised health value must not silently become a colour.

Acceptance

  • A Health line whose annotation mentions other states resolves to its actual value
  • A line reading - Health: **Degraded** *(was Healthy)* produces a red badge
  • An unrecognised or absent value fails loudly rather than picking a colour
  • Layer 0 coverage for all three, including the annotation case that produced this issue

Workaround in place

The 2026-08-25 snapshot's Health line was rewritten to avoid naming other states, and the badge is correct. That is a workaround in the data, not a fix in the tool, and it will not survive the next person writing a natural sentence.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions