docs(wp-0031): record verified OpenRouter diagnosis
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

Tested rather than relayed: OpenRouter answers 'User not found' for the
delivered key, which means no account resolves it — an existing-account key
reissue, not a new account. Ruled out credits (402), model permissions (403),
provider config, and pod health.

Also records a latent delivery defect: the secret carries a trailing newline,
harmless today only because llm_connect/config.py:53 strips it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-21 09:06:36 +02:00
parent 17f2caee01
commit 4f59845f51
2 changed files with 33 additions and 0 deletions

View file

@ -35,6 +35,7 @@
| workplan | ACTIVITY-WP-0029 | active | — | workplans/ACTIVITY-WP-0029-hub-port-alignment.md |
| workplan | ACTIVITY-WP-0030 | active | — | workplans/ACTIVITY-WP-0030-daily-sbom-catchup.md |
| workplan | ACTIVITY-WP-0031 | active | — | workplans/ACTIVITY-WP-0031-production-execution-reliability-cleanup.md |
| workplan | ACTIVITY-WP-0032 | proposed | — | workplans/ACTIVITY-WP-0032-glas-profile-execution-contract.md |
| workplan | ADHOC-2026-06-01 | finished | — | workplans/ADHOC-2026-06-01.md |
| workplan | ADHOC-2026-08-20 | finished | — | workplans/ADHOC-2026-08-20.md |
| workplan | custodian-WP-0001 | done | — | workplans/custodian-WP-0001-temporal-backbone.md |
@ -193,6 +194,11 @@
| task | ACTIVITY-WP-0031-T03 | done | — | workplans/ACTIVITY-WP-0031-production-execution-reliability-cleanup.md |
| task | ACTIVITY-WP-0031-T04 | done | — | workplans/ACTIVITY-WP-0031-production-execution-reliability-cleanup.md |
| task | ACTIVITY-WP-0031-T05 | wait | — | workplans/ACTIVITY-WP-0031-production-execution-reliability-cleanup.md |
| task | ACTIVITY-WP-0032-T01 | wait | — | workplans/ACTIVITY-WP-0032-glas-profile-execution-contract.md |
| task | ACTIVITY-WP-0032-T02 | wait | — | workplans/ACTIVITY-WP-0032-glas-profile-execution-contract.md |
| task | ACTIVITY-WP-0032-T03 | wait | — | workplans/ACTIVITY-WP-0032-glas-profile-execution-contract.md |
| task | ACTIVITY-WP-0032-T04 | wait | — | workplans/ACTIVITY-WP-0032-glas-profile-execution-contract.md |
| task | ACTIVITY-WP-0032-T05 | wait | — | workplans/ACTIVITY-WP-0032-glas-profile-execution-contract.md |
| task | ADHOC-2026-06-01-T01 | done | — | workplans/ADHOC-2026-06-01.md |
| task | ADHOC-2026-06-01-T02 | done | — | workplans/ADHOC-2026-06-01.md |
| task | ADHOC-2026-06-01-T03 | done | — | workplans/ADHOC-2026-06-01.md |

View file

@ -75,6 +75,33 @@ T01 still `wait`: the key rotation itself remains attended and
railiance-platform-owned. What changed is that the next failure will name its
own cause.
Diagnosis verified 2026-08-21 (previously relayed, now tested). Direct probe
from the llm-connect pod, no secret read or printed:
- `POST /execute` → `502 {"error":"provider_api_error","provider_status":401,
"message":"HTTP 401 from https://openrouter.ai/api/v1/chat/completions"}`
- `GET https://openrouter.ai/api/v1/key` with the delivered key →
**`401 {"error":{"message":"User not found.","code":401}}`**
"User not found" is OpenRouter's wording for a key that resolves to **no
account**. It is not insufficient credits (402) and not a model-permission
problem (403), so **no new OpenRouter account is required** — the existing
account needs a new key issued, because this key value is dead.
Key fingerprint for identification: `sha256[:12] = ab938241a2ec`, length 73
(+1, see below), prefix `sk-or-v1-`.
Ruled out along the way: provider/model config is correct
(`LLM_CONNECT_PROVIDER=openrouter`, `google/gemini-2.5-flash`); the Service and
pod are healthy; the ExternalSecret delivers exactly one key under the expected
name.
**Separate latent defect, railiance-platform lane:** the delivered secret has a
trailing newline (74 bytes for a 73-char key; `urllib` refuses it as a header
value outright). It is currently harmless only because
`llm_connect/config.py:53` calls `.strip()` on the env value. Any consumer that
does not strip would fail on a perfectly valid key. Worth fixing in the
OpenBao→ESO lane while the key is being replaced.
## Emergency-pause weekly SBOM fan-out
```task