recordPoolIdentityOnce censors the success side: a retry that worked and a retry that was never needed write byte-identical rows
GO given by pmmaster-evolutiva-cc on Elazar's behalf 2026-09-11. Named by db-terra-cc on TERRA-98 (marker POOL98-dnm9qk) as a one-line fix in the coder's lane, filed separately because TERRA-98's own sentence is provider/pooler root cause and stays blocked on telemetry outside this lane - this row is the instrument, not the cause, and closing one must not close the other. THE DEFECT. src/lib/pool-identity.ts:191-196, recordPoolIdentityOnce writes the success row with detail carrying only currentUser, sessionUser, isSuperuser, bypassRls. No attempt count. The failure side is fully instrumented - all four post-retry failures carry detail {attempts:2, transient:true} - so 'the retry works and saved N boots' and 'the retry works and was never needed' produce identical tables. Every reading of this series has argued the retry's value because nothing counts it. THE FIX. Add attempts to the success row's detail in recordPoolIdentityOnce, same key and same type as the failure path already uses, so the two sides join without a translation step. RETRY COUNT IS DECIDED AND IS NOT PART OF THIS ROW: it stays at 2. Do not add a third attempt. connectionTimeoutMillis is 10_000 (src/db/pool.ts:23), so each recorded failure is already at least 20 seconds of consecutive acquisition failure inside a waiting user's cold start. The premise at pool-identity-classify.ts:108-110 - 'a cold connect that succeeded milliseconds later, so a second attempt is what turns a recorded event into a non-event' - has ZERO confirming observations and FOUR contradicting it. Fix that comment in the same commit; leaving it there is the citation that will justify attempt three next time someone reads this file. ACCEPTANCE, and it is a coverage statement not a green check: after deploy, a query grouping success rows by detail->>'attempts' returns a non-null value for rows written after the deploy. State the deploy boundary in the result - rows before it have no attempts key and must not be read as attempts=1. Do not report a rate until the post-deploy population is larger than the six failures over 26 days that this row exists because nobody could interpret.
Activity
-
ALREADY SHIPPED BEFORE THIS ROW WAS FILED. Marker: T222-shipped-mtwz11. Both halves are live in 7edcb37 ("fix(TERRA-98,TERRA-209): stop censoring the retry and the reclaim, scaffold coder03/db03, pin the lane models", 2026-09-11 10:51), which is in origin/main. The row was filed at 09:58 for work committed roughly three hours earlier in the same lane. HALF 1 - the success row now carries the attempt count. src/lib/pool-identity.ts:215, `attempts: attempts + 1` inside the db:poolIdentity success detail, alongside currentUser/sessionUser/isSuperuser/bypassRls. THE `+ 1` IS DELIBERATE AND IS THE ONE THING A READER MUST NOT "FIX". The counter is incremented only in the catch, so on the success path it holds attempts that FAILED - 0 for a clean first try, 1 for a retry-saved boot. The failure rows record attempts that RAN. Emitting the raw counter would publish two different units under one key name, and the reader most likely to be misled is exactly the one joining success against failure rows, which is the entire purpose of the field. Both sides now mean attempts that ran: 1 = first try, 2 = the retry earned its place. The reasoning is in the comment at :200-214 so it survives the next refactor. HALF 2 - the falsified premise is corrected. pool-identity-classify.ts:108-121 no longer asserts "a cold connect that succeeded milliseconds later". It now states that the justification was FALSIFIED 0-for-4, cites db-terra-cc's measurement (marker POOL98-dnm9qk, agents/db-terra/evidence/2026-09-11-terra_98-poolidentity-denominator.result.md), gives the arithmetic (all four post-retry failures carry attempts:2 against connectionTimeoutMillis=10_000, so at least 20s of consecutive acquisition failure each), and says the retry is kept anyway with the reason. That was the point of the instruction: leave the dead premise in place and it is the citation that authorises attempt three. RETRY COUNT UNCHANGED AT 2, as ruled. Not revisited. WHAT IS NOT DONE AND IS NOT MINE - the acceptance is a MEASUREMENT, not a code state. Nobody has yet run the post-deploy query grouping db:poolIdentity success rows by detail->>'attempts'. Until someone does, this row has shipped an instrument whose output has never been read. Two conditions carry over to whoever runs it, from the row's own wording: state the DEPLOY BOUNDARY explicitly, because rows written before it have no attempts key and must not be read as attempts=1; and do not report a RATE until the post-deploy population exceeds the six failures over 26 days that made this row necessary. That is a db-lane query on TERRA-98, which stays open on provider root cause and must not close on this.
-
Shipped in 7edcb37, already in origin/main, three hours before the row was filed (T222-shipped-mtwz11). Success row carries attempts at pool-identity.ts:215; the falsified 0-for-4 premise at pool-identity-classify.ts:108-121 is corrected in the same commit. Retry count unchanged at 2. The post-deploy attempts query has NOT been run - it is a db-lane measurement on TERRA-98 and that row stays open.