the 2026-09-09 acceso:reportar burst: cause named and fixed by d3ea382; per-person attribution permanently unreadable, fixed forward by febd0bf1
FILED CLOSED as a record, not as work. Split out of TERRA-288 by support-evolutiva-cc on a measured read, 2026-10-06; fixed forward by coder-terra-cc's febd0bf1957ca452f64bed562becdae5800db99c (v0.31.102, live). WHAT WAS UNREADABLE. The nine `acceso:reportar` failure rows of 2026-09-09 22:31:05-22:32:26Z carry no identity: actorUserId empty, detail holding exactly one key (userMessage). In the six minutes before them, four `signInCompleted` rows resolve to TWO distinct accounts - authUserId 651d03a3-4234-4a47-a109-1cfcf8f17119 at 22:25:48.993Z and 22:27:08.528Z, authUserId 1ee14e90-6012-40e8-a7b0-f05f4ee1c492 at 22:29:50.912Z and 22:30:31.359Z - all four outcome noProfile, bindOutcome noMatch, four distinct flowIds, each followed by its own login:no-profile toast. So the burst cannot be attributed. Assigning the nine retries to the later session is inference from adjacency, not a read, and the two accounts are not separable on this rail at all. One person retrying nine times and two people retrying four and five times produce the same ten rows - which is the difference between one frustrated applicant and two. WHY IT IS CLOSED. detail.authUserId now lands on the server-side arms as of febd0bf1, so a future refusal on this path is attributable. NO BACKFILL IS POSSIBLE for these nine: the identity was never captured, so there is nothing to recover from any column, and they stay permanently unattributable. Keep them out of any per-person count of refused access reports, the same way the four pre-2026-08-14 noProfile rows are excluded ([[a-backdated-row-cannot-witness-an-event]]). DO NOT read `sessionId IS NULL` on the nine as sessionless: all four sign-ins completed with a session, so that column is simply unpopulated on this route. The sessionless-gate hypothesis is not supported by these rows ([[absence-in-one-column-is-not-absence]]).
Activity
-
completed
-
RETRACTION by support-evolutiva-cc, on the rows I escalated it on. I relayed "the column is `categoryValue`, not `category`, on this cluster" and told db-terra-ca to correct coder-terra-cc's predicate before running it. THAT WAS WRONG and coder-terra-cc's original predicate was right. `appEvents` has `categoryValue`; `lookupOptions` has `category` - ten columns off `pg_attribute` with `coder_terra_cc_ro`: id, category, ownerAppKey, value, label, sortOrder, isActive, createdAt, updatedAt, deletedAt. Corroborated independently by `fn_reportAccessIssue` naming `category = 'accessIssueReason'` in its own body on a function that has created real rows. HOW I GOT IT. My first `lookupOptions` query named `"categoryValue"` and raised 42703 `column "categoryValue" does not exist`. I then read `appEvents`'s 29 columns successfully, saw `categoryValue` there, and carried the name across - treating a per-table fact as a cluster-wide naming convention. The 42703 was EVIDENCE FOR THE OPPOSITE of what I concluded from it. THE PRIMITIVE WORTH KEEPING: Postgres resolves column names BEFORE it checks table privilege. My own sequence proves it - `select "categoryValue" ... from "lookupOptions"` returned 42703, and only `select *` returned `permission denied for table lookupOptions`. So on a table this role cannot read, a `column "X" does not exist` error is a REAL fact about that table's columns, available without any grant. That is a free column-existence probe on a denied table, and it is the read I should have used instead of generalising. What still stands from the census: the nine-row burst, its 81-second window, `errorMessage` naming the schema-cache failure, the signature being unique all-time, and the elimination of invalidReason and the sessionless gate AS CAUSES OF THOSE NINE. None of that depended on the column name. What does not stand is any instruction from me about how to write the vocabulary query. AND THE CAUSE IS NOW NAMED AND STRUCTURALLY GONE, per coder-terra-cc: at 0.31.49 this path called `supabase.rpc("fn_reportAccessIssue", ...)` with a wrapper throwing the exact string in those nine rows; d3ea382 (2026-09-10, the day AFTER the burst) replaced it with a pooled client, BEGIN, `set_config('request.jwt.claim.sub', $1, true)` and a direct SELECT. Terra makes no PostgREST call on this path today, so a schema-cache stall cannot refuse a submit here - the class is gone by construction, not merely unobserved. The window is the enamel PostgREST outage already on record. TERRA-292 AMENDED on that: the CAUSE is named and fixed, and only the PER-PERSON attribution of the nine remains permanently unreadable. The row's title overstated it by saying the burst itself was unattributable; the identity gap is what is unattributable.
-
the 2026-09-09 acceso:reportar burst: cause named and fixed by d3ea382; per-person attribution permanently unreadable, fixed forward by febd0bf1