Fix red main: literal i18n keys so TestI18nKeysDefined passes #564

Merged

Cordy merged 1 commit from fix-552d into main

2026-09-16 03:06:01 +00:00

Cordy commented

2026-09-16 03:02:36 +00:00

Owner

main is currently red and has been since v0.6.208. This is the fix, plus the explanation of how it got there.

The failure

--- FAIL: TestI18nKeysDefined (0.13s)
    webcheck_test.go:192: i18n keys used but not defined
                          (they would render verbatim): nc

ncWire built the message key by concatenation — tf("nc" + hit.charAt(0).toUpperCase() + hit.slice(1), …) — so the static scanner extracted the literal nc and could not verify any of ncDirGroup, ncAppGroup, ncDirAccount, ncLocalAccount. Replaced with one literal tf("…") per branch. The guard is right and the fix respects it rather than routing around it: a computed key is invisible to the scanner, so all four would ship unverified.

Runtime behaviour was never affected — the messages render correctly on the dogfood, which is exactly why this needed the static check to catch it.

How a red commit reached main — worth fixing properly

main is not a protected branch ("protected": false), so no status check is required to merge. merge_when_checks_succeed: true therefore does not gate on anything; it merges as soon as it next evaluates.

Combined with the house release train, that produces a specific race. The train pushes a one-shot workflow file to the PR branch and then dispatches it. That file push is itself a commit, which re-triggers evaluation — and the merge fires on it, seconds before the one-shot has finished doing its actual work:


`a8534bf` 02:33:34	workflow file for the keys fix pushed to `fix-552c`
`5e0af3d` 02:33:49	#561 merged — 15s later, CI red, fix not yet applied
`255c755` 02:58:38	workflow file for the retry pushed to `fix-552d`
`faa5038` 02:58:55	#562 merged — 17s later, same race
`d78edf1` 02:59	the retry finally pushes the actual fix — too late, already merged

So v0.6.208 and v0.6.209 were both tagged from a tree whose tests fail. The releases themselves are functionally sound, but "CI passed" was never true for them.

Two things worth changing, neither of which belongs in this PR:

Protect main and require the ci check. That makes merge_when_checks_succeed mean what its name says, and makes this class of race impossible rather than merely unlikely.
Until then, the train should verify the one-shot pushed and CI is green before calling merge at all, instead of scheduling the merge and trusting the gate. I have switched to that here.

Merging this one explicitly, after confirming the check is green — not on a schedule.

**main is currently red** and has been since v0.6.208. This is the fix, plus the explanation of how it got there. ## The failure ``` --- FAIL: TestI18nKeysDefined (0.13s) webcheck_test.go:192: i18n keys used but not defined (they would render verbatim): nc ``` `ncWire` built the message key by concatenation — `tf("nc" + hit.charAt(0).toUpperCase() + hit.slice(1), …)` — so the static scanner extracted the literal `nc` and could not verify any of `ncDirGroup`, `ncAppGroup`, `ncDirAccount`, `ncLocalAccount`. Replaced with one literal `tf("…")` per branch. The guard is right and the fix respects it rather than routing around it: a computed key is invisible to the scanner, so all four would ship unverified. Runtime behaviour was never affected — the messages render correctly on the dogfood, which is exactly why this needed the static check to catch it. ## How a red commit reached main — worth fixing properly `main` is **not a protected branch** (`"protected": false`), so no status check is required to merge. `merge_when_checks_succeed: true` therefore does not gate on anything; it merges as soon as it next evaluates. Combined with the house release train, that produces a specific race. The train pushes a one-shot workflow file to the PR branch and then dispatches it. That file push is itself a commit, which re-triggers evaluation — and the merge fires on it, seconds before the one-shot has finished doing its actual work: | | | |---|---| | `a8534bf` 02:33:34 | workflow file for the keys fix pushed to `fix-552c` | | `5e0af3d` 02:33:49 | **#561 merged** — 15s later, CI red, fix not yet applied | | `255c755` 02:58:38 | workflow file for the retry pushed to `fix-552d` | | `faa5038` 02:58:55 | **#562 merged** — 17s later, same race | | `d78edf1` 02:59 | the retry finally pushes the actual fix — too late, already merged | So v0.6.208 and v0.6.209 were both tagged from a tree whose tests fail. The releases themselves are functionally sound, but "CI passed" was never true for them. **Two things worth changing**, neither of which belongs in this PR: 1. **Protect `main`** and require the `ci` check. That makes `merge_when_checks_succeed` mean what its name says, and makes this class of race impossible rather than merely unlikely. 2. Until then, the train should **verify the one-shot pushed and CI is green before calling merge at all**, instead of scheduling the merge and trusting the gate. I have switched to that here. Merging this one explicitly, after confirming the check is green — not on a schedule.

Cordy added 1 commit

2026-09-16 03:02:37 +00:00