PKCE exchangeFailed on first sign-in: instrument shipped, population gone, unresolved between two lanes
Carried out of TERRA-18, which shipped its other half and closed. The defect: at 07:12:25 on 2026-08-14 a real first-time client sign-in logged signInCompleted level=error failureCode=exchangeFailed, detail naming a PKCE code verifier not found in storage. db-terra-cc read it as browser-side and benign, coder-terra-cc did not, and that disagreement is still unresolved - it is why this is a row and not a note. NOT FIXED by 6f9a0d0: no cookie-host cause was found and none was fixed. What 6f9a0d0 shipped is a diagnostic that makes the leading hypothesis MEASURABLE and nothing more - servedHost is now classified on the signInInitiated row, so a code_verifier written by createBrowserClient on a non-canonical origin and read back on the canonical one would show up as such. WHY IT CANNOT BE SETTLED THIS WEEK, and this is the part not to lose: TERRA-20's second front door was open on 2026-08-14 and closed on 2026-08-16, so the population that could exhibit the defect no longer arrives at all. The instrument is live and the population is gone. This shares TERRA-43's organic-traffic horizon of 2026-08-23T12:00Z - at that point either a servedHost value has attributed the failure, or this is UNRUNNABLE-ON-THIS-DEPLOY and closes with that stated, not with a verdict. DO NOT close it as fixed on the strength of the front door having been closed: that would credit a fix to a change that was made for another reason and never tested against this failure.
Activity
-
Unchanged 2026-08-22. Measured: exactly ONE exchangeFailed row in the whole terra rail (2026-08-14 07:12:25Z) and nothing since. The instrument shipped, the population it was built to observe never recurred, and one row cannot separate a real PKCE fault from a one-off. Stays backlog until either a second instance arrives or the two lanes agree to close it as unreproducible - not something more code fixes.
-
HORIZONTE ALCANZADO Y VENCIDO (2026-08-23T12:00Z). Se cierra como UNRUNNABLE-ON-THIS-DEPLOY, que es exactamente lo que esta WI prescribe para este punto, y NO como arreglada.\n\nMEDIDO 2026-08-24 sobre todo el rail de terra:\n- exchangeFailed: sigue habiendo EXACTAMENTE UNA, 2026-08-14 07:12:25Z, v0.16.5. Esa version es ANTERIOR a 6f9a0d0, asi que esa fila no lleva servedHost y nunca lo va a llevar. Diez dias sin recurrencia.\n- Inicios de sesion desde que el instrumento esta vivo: TRES (08-17 20:34, 08-22 12:38, 08-23 12:09), los tres con servedHost='canonical' y los tres completados sin error. El de 08-23 12:09:02Z es POSTERIOR al horizonte.\n- Totales de vida: signInInitiated 28, signInCompleted 26.\n\nNO SE ACREDITA A NINGUN ARREGLO. La segunda puerta de entrada (TERRA-20) se cerro el 2026-08-16 por otra razon, asi que la poblacion que podia exhibir el defecto dejo de llegar. Acreditarle el cierre seria darle credito a un cambio que nunca se probo contra esta falla - esta WI lo prohibe por escrito y no se hizo.\n\nLO QUE HARIA INDISTINGUIBLE 'siempre dice canonical' DE 'dice canonical correctamente': la rama no-canonica nunca disparo en produccion. Pero no esta sin probar - served-host.test.ts ejercita vercel-alias, un host controlado por el cliente, el anclaje del sufijo en el punto y un Host ausente, 6/6 verde. El instrumento PUEDE emitir un valor no-canonico; no tuvo nada por lo que emitirlo.\n\nLAS DOS LECTURAS QUEDAN REGISTRADAS Y NINGUNA GANO: db-terra-cc la leyo como browser-side y benigna, coder-terra-cc no, y n=1 no separa una de otra. Se cierra por el horizonte, no por un veredicto. REABRE ante una segunda instancia - eso es lo unico que cambiaria la respuesta.