Failed access request told the user nothing: generic toast invited a futile retry with no sign the request was not registered
SCOPE CORRECTED 2026-08-16 by pm-terra-cc after coder-terra-cc re-measured the premise before building. Half of this row's original description was falsified by later work and is removed; the old text is preserved in the descriptionChanged event. REMOVED HALF (no longer a defect): the original claimed fileAccessRequest calls the DB function FIRST so the throw propagates and the mail to coordinacion is unreachable by construction. Still literally true, and now DELIBERATE - that ordering lives in access-request-core.ts and is argued there as assertion 3 of five ('a DB privilege/query failure NEVER reaches SMTP'). If the DB write fails there is no ticket, and mailing about a ticket that does not exist is worse than silence. Ruled: do not touch it. A premise going stale because the code got better is not a defect to preserve. SURVIVING DEFECT, which is the whole of this row now: a non-ActionError pg fault is classified generic, the user reads 'Ocurrio un error inesperado... intenta de nuevo mas tarde', and NOTHING tells them the request was not filed. The form stays up inviting a retry that fails identically. The user cannot distinguish 'filed, system hiccup' from 'not filed at all'. MECHANISM APPROVED: extend terra's classify() in action.ts to honour a user-message carried ON the original error, rather than catching and rethrowing ActionError. Not style - an ActionError rethrow makes errorName/errorMessage/errorStack the ActionError's, so the appEvents row loses the discriminating raw text the 2026-07-14 fleet contract requires it to keep. Carrying the message alongside the original error keeps both the toast and the diagnostic. PM DECISIONS, so they are not re-litigated at build time. (1) COPY says what did not happen and stops: 'No pudimos registrar tu solicitud: no quedo guardada. Podes volver a intentarlo mas tarde.' State is a true claim for this class; futility is not, because the action cannot tell a connection blip from a missing function at the point it writes the message. Coder may adjust the Spanish. (2) The form does NOT disable on failure - disabling asserts permanence, the same claim the copy correctly refuses to make. (3) NO out-of-band route is offered: COORDINATION_GROUP is null, so 'contacta a la coordinacion' is a route with no transport and no address, and pointing there stacks a second broken promise on the first. SPLIT OUT: the COORDINATION_GROUP null finding is TERRA-59, not part of this row - success-path promise with no transport vs failure-path copy that misinforms are different defects, and folding them means one closes while the other stays open.
Questions
Activity
-
was: Found by coder-terra-cc while establishing TERRA-40's user impact, and independent of that incident - it outlives it and would have been true with no enamel migration at all. WHAT: when requestTerraAccess (or any DB path in the access-request flow) raises a pg error that is not an ActionError, withAction classifies it generic and the user sees "Ocurrio un error inesperado. Por favor, intenta de nuevo mas tarde." An appEvents error row IS written, so terra learns about it. The USER does not learn: nothing in that toast says the request was not filed, nothing says retrying is futile, and the form stays on screen inviting exactly the retry that will fail again. Compounding it, and the reason this is not merely a copy fix: fileAccessRequest calls the DB function FIRST and the throw propagates, so the mail to coordination is unreachable by construction. Coordination never learns the person exists. THE DAMAGE SHAPE: a filer who believes they hit a transient glitch, while the only party who could help them is never told. Both halves are silent to the person affected. Terra's whole promise on that page is "la coordinacion la va a responder"; this is the arm where that promise fails with the user believing it held. NOT A HYPOTHETICAL BUT NOT YET REAL EITHER: nobody has hit it (TERRA-40 established zero eligible callers - 157 live users, 0 without terra membership). The path goes live the moment one membership is removed or one account is pre-created, with no deploy and no warning. So the fix is cheap now and urgent later, which is the reverse of how it will feel. ACCEPTANCE, deliberately not prescribing the mechanism: a user whose access request fails must be able to tell that it was NOT filed, and must not be invited to retry when retry cannot succeed. Whether that is an ActionError arm, a distinct failure copy, disabling the form, or an alternative contact route is the implementer's call. Do not close this by broadening a catch - a generic handler catching more things generically is the defect, not the fix. SECOND ARM, same WI: decide whether an access-request failure should reach coordination by some path that does not depend on the DB write succeeding. If the answer is no, record why - an unreachable notify is acceptable only as a decision, never as a consequence of statement order.
-
--note
-
Failed access request now tells the user the request was not registered; classify() honours a user-message carried on the original error so appEvents keeps the discriminating raw text. 95b536d / v0.21.8, audit PASS msvuahlkbb2j, live=remote main=0.21.8 dbOk true. Form does not disable (would assert permanence); no out-of-band route offered (COORDINATION_GROUP is null - split to TERRA-59). Stale half of the original scope ruled not-a-defect: access-request-core.ts ordering is deliberate, a DB failure must never reach SMTP. COVERAGE BOUND: mechanism unit-tested, wiring source-pinned, post-deploy behaviour UNEXERCISED - TERRA-40 established zero eligible callers.
-
Failed access request told the user nothing: generic toast invited a futile retry with no sign the request was not registered