image lane bakes better-auth 1.5.5 while npm lane resolves 1.7.1 — 1395 fix dormant in containers until an image bakes >=1.7.1 #1420

Open
opened 2026-08-25 14:45:23 +00:00 by ops-deploy-01 · 0 comments
Member

Found during P3 E5 verification (usc/infrastructure #272/#273) — re-pin to sha-b2d40da (pipeline 2669, next@b2d40dada).

Measured: the gateway IMAGE's real resolved better-auth is 1.5.5 — /app/node_modules/.pnpm/[email protected]_... inside the container (note: a hoisted top-level duplicate can mislead; the .pnpm directory is the truth). The npm lane resolves 1.7.1 (web1's npm install hits it). 1395's trigger is better-auth 1.7.1 reading accounts.issuer, so password-auth on the image lane does not exercise PR #1401's fix at all — it is dormant in containers until an image bakes better-auth >= 1.7.1.

Consequence: containerized deploys cannot validate the 1395 fix (the E5 sign-in arm passes trivially under 1.5.5, which never reads issuer — a PASS that proves nothing about 1401). This issue is the tracking hook for the eventual real 1395-flip verification: when an image ships >=1.7.1, re-run the dark-verify sign-in arm against a fresh DB and expect it to pass BECAUSE of 1401 rather than because of version lag.

Adjacent field validation that DID land at sha-b2d40da (recorded here because this issue is the container-lane tracking point): on an existing ledger-17 database, boot auto-applied migration 0017 via the #1403 hash-ledger core → accounts.issuer created BY MIGRATION → ledger 18/18 → gateway schema-verified. So 1401's migration + 1403's migrator are proven on a real 17→18 upgrade; only the runtime better-auth leg is version-blocked.

Ask: refresh the image lane's better-auth pin (lockfile) to match the npm lane's resolution, or document the supported pairing; then publish and flag here so the E5 re-verification can run. Consumer: P3 dark deploy (usc/infrastructure #272), flip gate. Found by ops-deploy-01 (P3 E5 report to fred); fred directed the filing.

Found during P3 E5 verification (usc/infrastructure #272/#273) — re-pin to sha-b2d40da (pipeline 2669, next@b2d40dada). **Measured:** the gateway IMAGE's real resolved better-auth is 1.5.5 — /app/node_modules/.pnpm/[email protected]_... inside the container (note: a hoisted top-level duplicate can mislead; the .pnpm directory is the truth). The npm lane resolves 1.7.1 (web1's npm install hits it). 1395's trigger is better-auth 1.7.1 reading accounts.issuer, so password-auth on the image lane does not exercise PR #1401's fix at all — it is dormant in containers until an image bakes better-auth >= 1.7.1. **Consequence:** containerized deploys cannot validate the 1395 fix (the E5 sign-in arm passes trivially under 1.5.5, which never reads issuer — a PASS that proves nothing about 1401). This issue is the tracking hook for the eventual real 1395-flip verification: when an image ships >=1.7.1, re-run the dark-verify sign-in arm against a fresh DB and expect it to pass BECAUSE of 1401 rather than because of version lag. **Adjacent field validation that DID land at sha-b2d40da (recorded here because this issue is the container-lane tracking point):** on an existing ledger-17 database, boot auto-applied migration 0017 via the #1403 hash-ledger core → accounts.issuer created BY MIGRATION → ledger 18/18 → gateway schema-verified. So 1401's migration + 1403's migrator are proven on a real 17→18 upgrade; only the runtime better-auth leg is version-blocked. **Ask:** refresh the image lane's better-auth pin (lockfile) to match the npm lane's resolution, or document the supported pairing; then publish and flag here so the E5 re-verification can run. Consumer: P3 dark deploy (usc/infrastructure #272), flip gate. Found by ops-deploy-01 (P3 E5 report to fred); fred directed the filing.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1420