[hartmark]

What Problem This Solves

Every API route was crashing with a next-intl INVALID_KEY error and surfacing to callers as a bare 404 — GET /api/health/ping 404, and any authenticated request to /v1/models / /v1/responses / etc. hit the same crash. Found while running live workload tests against omniroute-beta.

next-intl treats . in a message key as a namespace separator. Every locale file in src/i18n/messages/ had two spots with flat keys containing literal dots:

• resilienceConnections had four "degraded.source.X" keys as siblings of resilienceConnections.degraded, which is itself a plain string ("Partial data: unavailable sources: {sources}") — so nesting them under degraded directly wasn't an option, it already holds a string.
• Four top-level "capabilityFilter.X" keys, unused by any real i18n call site today (the only other match for capabilityFilter. in the codebase is an unrelated import path referenced in a chatCore.ts comment).

next-intl validates the full key structure of a locale file at load/module-init time regardless of whether individual keys are ever read, so this broke every route touched by the i18n middleware — not just pages that render the resilience-connections UI.

Why This Change Was Made

Renamed the dotted keys into real nested objects: resilienceConnections.degradedSource.X and a top-level capabilityFilter object. This is the structurally correct shape next-intl expects; the alternative (keeping the flat dotted string but escaping the dot some other way) doesn't exist in next-intl's key model.

User Impact

Every authenticated API request and the health-check endpoint currently 404s. This restores them. No translated text changed — only key structure. Verified live: /api/health/ping and /v1/models went from 404 (crash) to 200/401 (correct) on the same running instance after this fix.

Evidence

• Values are byte-identical in every one of the 43 locale files — only key nesting changed, no translated string was touched.
• Updated the one real caller (ResilienceConnectionsClient.tsx's t(\degraded.source.${s}`)→t(`degradedSource.${s}`)`) and its test's assertion on the same string.
• Unrelated to the request-logger-keepalive-capture work happening alongside this on the same testing session, but it made every API route unusable for live testing, so fixing it here rather than working around it.

Test plan:

• All 43 locale JSON files re-validated as parseable JSON after the transform; spot-checked en.json's before/after values are unchanged
• npx vitest run tests/unit/ui/resilience-connections.test.tsx: 17/17 passing (was failing before, asserting the old broken key literally appearing in rendered output)
• tsgo --noEmit: clean
• Live: /api/health/ping and /v1/models on the running omniroute-beta container went from 404 (INVALID_KEY crash) to 200/401 after this fix

[diegosouzapw]

Hey, thanks for the sharp catch and for the live verification against omniroute-beta — the INVALID_KEY crash you diagnosed here was real and nasty (killing every authenticated API route, not just the i18n-rendered pages).

Since this PR was opened, the identical fix landed on release/v3.8.50 as part of PR #10418 (merged 2026-08-15), which independently restructured the same dotted keys across all 43 locale files. It used a slightly different shape than yours (resilienceConnections.degraded became { message, source: {...} } rather than a sibling degradedSource object), but the net effect — no more literal dots in message keys — is the same, and I've confirmed against current tip that no dotted keys remain anywhere in the locale files. That's why GitHub is now showing this PR as conflicting with the base.

One thing your PR does that the merged fix didn't: pt.json's capabilityFilter.* strings are still untranslated English placeholders on the current tip, and your diff correctly translates them into Portuguese (and also cleans up a real duplicate-key issue that was in pt.json's degraded block). That part is still a genuine improvement worth landing — if you're up for it, a small follow-up PR with just those 4 Portuguese strings against current release/v3.8.50 would be very welcome and easy to merge.

Given the core fix is already shipped, I'll be flagging this one to the maintainer as subsumed rather than merging it — but really appreciate the diagnosis and the live-testing rigor, that's exactly the kind of evidence we want on bug fixes. If you'd like to send the pt.json translation fix as a small standalone follow-up, that part is still very welcome.

[diegosouzapw]

Babysit summary

Drove CI to green. Result: all non-advisory gates pass — ready for human review/merge.

Root cause of the red: the Fast Quality Gates failure was STALE, not a defect. The branch was 60 commits behind release/v3.8.50 (created 08-14; the failing run was frozen at the pre-refresh SHA). Its only red gate was dead-code, a ratchet counting 410 dead symbols against baseline 409.

What I did:

• Refresh-merged the PR branch onto the green base tip 774127be3, resolving the i18n-message + ResilienceConnectionsClient conflicts in favor of the base's canonical, tested structure.
• ⚠️ Important for the reviewer: the base tip already contains an equivalent fix for this exact dotted-translation-key bug — it nests resilienceConnections.degraded.message / degraded.source.* and capabilityFilter as a real object, and ships the tests/unit/i18n-nest-dotted-keys.test.ts guard. The PR's fix is subsumed by the base; the merged tree is byte-identical to origin/release/v3.8.50. I aligned the merge to the base's shape (rather than the PR's alternate degradedSource variant) to keep the branch coherent with base's caller. The PR's i18n-nest-dotted-keys test passes 4/4 against the merged tree; check:dead-code is 249 vs baseline 415.
• Pushed to the hartmark fork head 53b0376 (headRefOid verified changed).

dast-smoke note: the first run appeared red but its real conclusion was cancelled — the self-hosted runner hit the 30-min ceiling before any DAST/schemathesis/promptfoo test executed (known infra signature, not an assertion failure). Re-ran the job; it passed (9m39s).

Final gh pr checks 10332 (all non-advisory passing):

• Build (advisory) / Fast Quality Gates: pass
• Formula/Unit tests 1-4, Vitest (fast-path), No new ESLint warnings, Docs Gates, Merge integrity, Change Classification, semgrep (+cloud): pass
• dast-smoke: pass
• No unresolved review threads.

Recommendation: since the base already carries this fix, the reviewer may treat the merge as effectively subsumed — but the branch is green and ready. Handing off for human merge (not merged here).

[hartmark]

Checked the optional follow-up you suggested (pt.json capabilityFilter.* Portuguese translations + duplicate-key cleanup in the degraded block).

Verified against current release/v3.8.50 tip: src/i18n/messages/pt.json already has genuine Portuguese translations for all 4 capabilityFilter.* strings (not English placeholders) — e.g. capabilityFilter.visionMismatch = "O fornecedor não suporta visão para este pedido de imagem", distinct from en.json's "Provider does not support vision for this image request". No literal duplicate "degraded" key exists in the file either (7 occurrences, all at different nesting levels/objects). This was already resolved upstream (presumably as part of #10418 or a related pass) since the review comment was written, so no follow-up PR needed.

[diegosouzapw]

Hi @hartmark — thanks for the careful diagnosis (the next-intl INVALID_KEY crash from dotted keys is real). The same structural fix already merged into release/v3.8.50 via #10418 (2026-08-15), so this PR now conflicts with the base and adds nothing on top. Closing as subsumed by #10418. If the capabilityFilter.* PT strings still show untranslated on tip, that'd be worth a fresh PR targeting only that — happy to help scope it.