inventory.mjs reports ok for pins whose tag it cannot parse #109

New issue

Closed

opened 2026-09-23 10:46:23 +01:00 by cruelacid · 1 comment

cruelacid commented

2026-09-23 10:46:23 +01:00

Owner

Why

deploy/inventory.mjs cannot answer two of its own three questions for a pin
whose tag is not numeric, and reports ok rather than saying so.

tagLines() returns null for anything non-numeric — the comment says as much:

if (!m) return null;             // `latest`, a date tag, something bespoke

compare() then gates both remaining checks on the result: the lag flag needs
newestInLine, and the line flag needs newestAny && newestInLine. With
neither, the row renders ok, blank mark, IN LINE ?, no note.

That contradicts the file's own stated rule:

"It never reports a component as current on the strength of an absent answer."

And it is a near-relative of the failure the file was written for. The comment
sitting a dozen lines above the gap says it outright:

"It is exactly what made louislam/uptime-kuma:1 look permanently healthy: the
pin was current, and a whole major behind, at once."

A floating tag is the more extreme version of that — current by definition, on a
tag that can move per commit.

Severity: latent, not live

Checked 23 September 2026: every pin on the fleet today is numeric —
caddy:2, glitchtip/glitchtip:6.2, louislam/uptime-kuma:1,
postgres:18-alpine, valkey/valkey:9-alpine,
bbernhard/signal-cli-rest-api:0.100. All return a valid tagLines object, so
nothing is being misreported right now.

The bug bites the day someone adds :latest, :main, or a date tag — which is
how it was found, while costing out a getfider/fider:main pin.

What to do

Teach compare() that it cannot answer, rather than letting silence read as
health:

// in compare(), after the lag block
if (!tagLines(p.pin)) {
  flags.push('unversioned');
  notes.push('a moving tag — this checker cannot answer lag or line for it');
}
// and with the other level rules:
if (flags.includes('unversioned') && level === 'ok') level = 'note';

note rather than amber: a deliberate floating pin is a decision, not a
regression. The point is that the table stops claiming an answer it does not
have.

Verification

Add the case to deploy/test/inventory.test.ts and mutation-check it both
ways: a non-numeric pin must get the flag, and a numeric pin must not. The
second half is the one that matters — a flag that fires on everything is as
useless as one that fires on nothing.

## Why `deploy/inventory.mjs` cannot answer two of its own three questions for a pin whose tag is not numeric, and **reports `ok` rather than saying so.** `tagLines()` returns `null` for anything non-numeric — the comment says as much: ```js if (!m) return null; // `latest`, a date tag, something bespoke ``` `compare()` then gates both remaining checks on the result: the `lag` flag needs `newestInLine`, and the `line` flag needs `newestAny && newestInLine`. With neither, the row renders `ok`, blank mark, `IN LINE ?`, no note. That contradicts the file's own stated rule: > "It never reports a component as current on the strength of an absent answer." And it is a near-relative of the failure the file was written for. The comment sitting a dozen lines above the gap says it outright: > "It is exactly what made `louislam/uptime-kuma:1` look permanently healthy: the > pin was current, and a whole major behind, at once." A floating tag is the more extreme version of that — current by definition, on a tag that can move per commit. ## Severity: latent, not live **Checked 23 September 2026: every pin on the fleet today is numeric** — `caddy:2`, `glitchtip/glitchtip:6.2`, `louislam/uptime-kuma:1`, `postgres:18-alpine`, `valkey/valkey:9-alpine`, `bbernhard/signal-cli-rest-api:0.100`. All return a valid `tagLines` object, so nothing is being misreported right now. The bug bites the day someone adds `:latest`, `:main`, or a date tag — which is how it was found, while costing out a `getfider/fider:main` pin. ## What to do Teach `compare()` that it cannot answer, rather than letting silence read as health: ```js // in compare(), after the lag block if (!tagLines(p.pin)) { flags.push('unversioned'); notes.push('a moving tag — this checker cannot answer lag or line for it'); } // and with the other level rules: if (flags.includes('unversioned') && level === 'ok') level = 'note'; ``` `note` rather than amber: a deliberate floating pin is a decision, not a regression. The point is that the table stops claiming an answer it does not have. ## Verification Add the case to `deploy/test/inventory.test.ts` and **mutation-check it both ways**: a non-numeric pin must get the flag, and a numeric pin must **not**. The second half is the one that matters — a flag that fires on everything is as useless as one that fires on nothing.

cruelacid added this to the Backlog - unscheduled milestone

2026-09-23 10:46:23 +01:00

cruelacid added the

area:ops

label

2026-09-23 10:46:23 +01:00

cruelacid referenced this issue

2026-09-23 10:46:56 +01:00

Go-to-market programme #110

cruelacid commented

2026-09-23 18:55:54 +01:00

Author