Las pantallas tiraban el requestId del servidor

Sub-tickets — 2/2 done

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus note · 5w ago
  CORRECCION DE MEDICION. El cuerpo del commit e9fb309a dice 'CERO <ErrorModal> en todo el repo sin requestId'. Es FALSO y salio de un scan roto: el regex era <ErrorModal\b[^>]*?/> y un prop como onClose={() => router.push('/')} tiene un > adentro, asi que la clase [^>] cortaba dentro del arrow y el bloque no matcheaba nunca. El cero era del escaner, no del repo. Re-medido con conteo de llaves sobre dev@c55d72ea: 85 call sites de ErrorModal/ErrorPage, 48 SIN prop requestId. Los 48 son la clase que este ticket dejo fuera a proposito (error nacido en el cliente, sin error de servidor que correlacionar) y ErrorModal les acuña el id por MOVILBA-404, asi que el codigo shipeado no cambia. Enunciado correcto: todo camino que RECIBE un requestId del servidor ahora se lo pasa al modal. Regla que queda: un regex sobre JSX no puede usar una clase negada de >, y un cero de un scan es una afirmacion sobre el ESCANER hasta que el escaner matchee un positivo conocido.
• wi-cli-venus assigned · 4w ago
  coder03-mba-l-cc / coder
• coder03assistant-mba-l-ca progress · 3w ago
  coder03assistant-mba-l-ca | 2026-09-24 04:11:32 ART | dev 7d299b6a / main 721b9eb8 requestIdDelServidor helper exists and current UI callers pass extracted IDs; previous event corrected broken JSX scanner and scoped claim to server-origin IDs. Full current caller census and browser propagation not independently exercised in this sweep; keep open.
• coder03-mba-l-cc assigned · 2w ago
  coder04-mba-l-ca
• audit-mba-l-cc audit-finding · 1w ago
  MOVILBA-407 - correlation surface gap reported by the proxy lane, filed here rather than as a new item because it is the same family: there is NO x-request-id RESPONSE header on success. The requestId reaches the caller only as a top-level field in the JSON body, confirmed by the proxy lane on /api/vehiculos and /api/user/profile. Consequence: a caller who gets a non-JSON error or a 500 has nothing to correlate with, which is exactly the case where correlation matters. Not verified by me with a live request; recorded as the proxy lane reported it. Not a blocker on MOVILBA-735. Code pointers if someone picks it up: src/proxy.ts:357-360 and :387-390 DELETE the context headers from the response, so adding x-request-id there is a deliberate re-add, not an omission.
• coder03-mba-l-cc assigned · 1w ago
  researcher-mba-l-cc / solo
• coder03-mba-l-cc statusChanged · 1w ago
  coder03-mba-l-cc 19:26Z - reassigned from coder04 to the researcher lane as a read-only census. It feeds 739 directly: audit measured 42 generateUUID/randomUUID mints still inside 739's scope, and the screens dropping the server requestId are the client half of the same invariant. coder04 is saturated with the service/repository half.
• researcher-mba-l-cc note · 1w ago
  2026-10-08T16:28:08-03:00 / 19:28:08Z researcher-mba-l-cc. Client-side census for 407, read-only, service/repo half left to coder04. MECHANISM: src/utils/error-handling.ts:74-80 `requestIdDelServidor(e)` extracts a server-issued id from either shape (server-action `{success:false,error,requestId}` or `ApiError` from lib/api-client.ts, which the function's own comment at :66 says "lleva requestId publico"). `createErrorInfo()` at :105 does the right thing WHEN FED ONE: `params.requestId || generateUUID()` - mints fresh only on no input. The defect is not in this shared function, it is that almost nothing calls it with a requestId. CENSUS - 35 createErrorInfo() call sites across 20 files (full brace-matched scan, not a line-window grep): - 33 of 35 (18 of 20 files) never pass `requestId` at all -> always mint a fresh client UUID, even on a server-originated error. Every one of these 20 files ALSO calls `isApiError(err)` at least once in the same catch chain (1-3 times per file), so the reachable-ApiError-with-a-real-requestId case is confirmed present in all 20, not hypothetical. - 2 of 35 (vehiculos/[dominio]/editar/colectivo/page.tsx:735-740, vehiculos/agregar/colectivo/page.tsx:366-371) correctly pass `requestId: result.requestId` from a server-action result - these two sites are NOT broken, cite as the working example. - Representative confirmed-reachable drop, not inferred: src/app/ramales/page.tsx:97-108 branches on `isApiError(err)` for its user-message text, then at line 106 calls `createErrorInfo({message, endpoint, error: err, userMessage})` with no `requestId:` key - the ApiError's own public requestId (confirmed to exist on the type, lib/api-client.ts) is in scope at that exact line and is discarded. SEPARATE, already-correct population: 8 files call `requestIdDelServidor()` directly into `setErrorRequestId()` (legacy state-setter pattern, e.g. src/app/paradas/page.tsx:71) - these DO extract and surface the server id. Not part of the defect. THIRD population - 13 files have a catch block that touches NEITHER helper at all: src/app/admin/analisis-importacion/page.tsx, admin/audit-log/page.tsx, admin/carrocerias/agregar/page.tsx, admin/fabricantes/agregar/page.tsx, admin/opciones/[id]/page.tsx, admin/page.tsx, auth/verify-email/page.tsx, entidades/[id]/page.tsx, lineas/agregar/page.tsx, reset-password/page.tsx, user/login/LoginForm.tsx, vehiculos/[dominio]/editar/page.tsx, vehiculos/page.tsx. Spot-checked src/app/vehiculos/page.tsx:125,142-146: `.catch(() => {...})` with no bound error parameter at all - the error is discarded before any id question can even arise, no client-side log() call either. This is a DIFFERENT defect shape than 407's premise (nothing to drop because nothing is captured), not re-derived for the other 12 - flagging as present, not characterized file-by-file. WHAT THE CLIENT SENDS INSTEAD, traced end to end: `logAndShowError`/`registrarError` (error-handling.ts:168-184,195-220) call `log()` with `errorInfo.requestId` - the SAME id shown to the user in the modal, per its own comment at :218. For the 33 broken call sites that id is the just-minted client UUID, which `log()`'s browser branch (logger.ts, `typeof window==='undefined'` guard) does NOT insert locally but DOES forward to `/api/log-error` (per the comment at error-handling.ts:211-216, MOBAAPI-641). So the client sends a freshly-minted UUID to `/api/log-error`'s app_logs row, orphaned from whatever id the server's own row used for the same failure - two rows, no correlation, exactly the failure mode the function's own doc comment (lines 69-72) says must not happen, and 33 of 35 call sites cause it anyway. NOT A NO-OP: 407 is a real, reproducible defect at 33 of 35 wired call sites across 18 files, confirmed via the always-present isApiError branch, not inferred from absence. NOT COVERED: the other 12 of the 13 fully-untouched files were named, not individually traced to their catch-block behavior (vehiculos/page.tsx was the one spot-check). No DB/app_logs readback confirming orphaned-pair rows exist in practice - this is source-only. Did not check whether `ApiError`'s requestId field can itself be undefined/empty at runtime (would make requestIdDelServidor's own undefined-return path the correct one, not a bug) - the function already guards for that (error-handling.ts:77, string+nonempty check), not verified against a live ApiError instance. Did not touch the service/repository half per coder03's instruction (coder04's scope, MOVILBA-542-adjacent).
• researcher-mba-l-cc statusChanged · 1w ago
• coder03-mba-l-cc assigned · 1w ago
  coder03assistant-mba-l-ca / coder
• coder03-mba-l-cc progress · 1w ago
  coder03-mba-l-cc 19:31Z - census complete (researcher), fix reassigned to the coder03assistant lane. This ships WITHOUT a GO under the 2026-09-18 rule: it is BROKEN, not a feature, and there is nothing to choose - the correct pattern already exists in-repo at the two vehiculos colectivo add/edit sites that pass result.requestId, so the 33 sites in 18 files are a mechanical change to that same shape. The 13 files that use neither helper are NOT in scope and are filed as MOVILBA-741: a fix here must not claim coverage of them. The 8 files on requestIdDelServidor() are already correct and are not to be touched.
• audit-mba-l-cc audit-finding · 1w ago
  # MOVILBA-739 repo/service tail + MOVILBA-407 — audit verdict audit-mba-l-cc, 2026-10-08. Lock `gates-checkout-movilba-web` held by audit for the whole window. **One gate run covered all 24 modified `.ts/.tsx` files**, because all of them were in the shared checkout at the same tree state; I am not claiming two independent runs. ## Pins (sha256, identical before AND after the gate runs) src/repositories/paradas.ts d5cc7262d36f23ce709aca3d2ea44308a04269fccf6d2bece4f9eb4a721f459f src/repositories/recorridos.ts 682d563e20c975673b9ca4ddb58a5aa73a32b76b311e033cd6449786e282e5a8 src/services/personas.ts 05c5b2bc0394d71992a08145087dbac3a3e5383eb1de197c892354ddc279b733 src/repositories/personas.ts d70c275067a12b28d5405ae1bd34d6273aecdb1d0bc462e364568ff2c88060b5 MOVILBA-407 src/app diff 5d162ea496a28f64628d4f7214580bd34b23461f1f95932152103884ba212ff4 All four 739 hashes match coder04's claims exactly. The 407 diff hash matches coder03assistant's claim exactly, reproduced two ways (`git diff -- src/app` and the explicit 20-file list). ## Gates — run by audit, over all 24 files eslint --max-warnings 0 (24 archivos) exit 0, limpio pnpm typecheck (next typegen && tsc) exit 0 pnpm test:source 66/66, fail 0 pnpm test:tools 114/114, fail 0 (ver flake abajo) gate postman --check exit 0, al dia (20 carpetas, 100 requests) **`test:tools` flaked once and I am reporting it rather than only the green re-run.** The first invocation exited 1 with a Postgres `ProcessInterrupts` / statement-cancellation error raised *outside* the assertions — the suite itself still reported 114 pass / 0 fail. Two further runs exited 0 with 114/114. So 1 of 3 runs failed on an external-DB cancellation, not on this diff: the suite globs `tools/tests/*.test.*js` and none of the 24 files is under `tools/`. Known shape (MOVILBA-538, dbcaba reachability). I did not patch or skip the gate. ## MOVILBA-739 — paradas / recorridos repo tail — PASS Clean 1:1 substitution, no signature churn. `randomUUID` and `generateUUID` are both at **0** occurrences in all four files, and no `utils/uuid`, `node:crypto` or `from 'crypto'` import survives in any of them. The four paradas mints (`findMany`, `findById`, `create`, `update`) and the four identical recorridos mints become `await getRequestId()`; all methods were already `async`. **The end-to-end invariant, checked rather than inferred from a mint count.** The repositories do not receive the id by parameter — they re-resolve it with `getRequestId()`, which reads the same async context the route installed, so route, service and repository converge on one id per request. Separately, `softDelete(id, userId, requestId: string)` in **both** repositories keeps its explicit parameter and `services/{paradas,recorridos}.ts` pass their own `requestId` straight through (`recorridos.ts:145`). That path propagates by argument and is correctly **outside** this hunk's scope. coder04's "8 entry mints only" is accurate as stated. ## MOVILBA-739 — personas service + repository — PASS Same shape: 7 assignments in `src/services/personas.ts` and 4 in `src/repositories/personas.ts` converted, imports moved from `crypto` to `@/lib/request-context`, `randomUUID`/`generateUUID` at 0 in both, all methods already `async`. ## MOVILBA-407 — PASS **The "33 sites" claim is correct and I initially mis-measured it.** A balanced-paren scan of every `createErrorInfo(` call in `src/app/**/*.tsx` finds **36** sites: **35** carry a `requestId`, split **22 `requestIdDelServidor(err)` + 11 `requestIdDelServidor(error)` = 33**, plus **2 `result.requestId`**. My first count of 11 saw only the `(error)` spelling and missed the 22 `(err)` ones; a single-line `grep` also returned nothing at all because these calls span lines. Withdrawn. The **1** site with no `requestId` is correct as-is: `src/app/admin/fabricantes/[id]/editar/page.tsx`, `'Invalid fabricante ID'` — a pure client-side validation with no server round-trip, so there is no server id to correlate to. The 2 `result.requestId` sites take the id from a server action's own result, which is the more direct source where no error was thrown. Diff is 20 files, 74 insertions / 41 deletions. ## Finding — applies to 407, not blocking **The server id is best-effort, and when it is absent the fallback is silent.** `requestIdDelServidor` (`src/utils/error-handling.ts:74`) returns `string | undefined` — it yields an id only when the thrown value is an object with a non-empty string `requestId` property. `createErrorInfo` then does `const requestId = params.requestId || generateUUID()`. So an error that does not carry `requestId` produces a **freshly minted client UUID with no `app_logs` counterpart**, which is the exact defect class 407 and 739 exist to remove — and it is invisible, because the modal still displays an id. This is intentional per the MOVILBA-321 doc comment on the parameter ("solo se acuña cuando el error nace en el cliente y no existe linea de log del servidor a la cual correlacionar"), and the diff is strictly better than what it replaces. What is *not* established is how often the runtime error actually carries the property at these 33 sites. ## NOT EXERCISED - **No test asserts anything about requestId resolution.** The only test file in the tree that names `createErrorInfo` is `tools/tests/colectivo-edit-load.test.cjs:70`, and it **stubs it to identity** (`export const createErrorInfo = x => x;`). `requestIdDelServidor` is named by no test at all. Coverage of the 407 change by the test suite is zero; the green 114/114 says nothing about it. - **No live HTTP request was issued against any of this**, so no `app_logs` row was observed carrying a shared id, and the fallback-mint rate at the 33 sites is unmeasured in both bases. The grouped `app_logs` post-deploy control coder04 names as outstanding is still owed and is the only thing that would settle it. - `next build` was not run — no ship path runs it, so a build-breaking change would pass every gate above. - `lint:strict` was not run (baseline-red on vendored `public/scalar`); eslint was scoped to the 24 modified files. - MOVILBA-739 remains **open**: the converted paths are the entry mints only. Mints elsewhere in `src/services`, `src/repositories` and `src/app/api/log-error/route.ts` are untouched, and coder04 states it is still classifying the fallback/default-param mints.
• audit-mba-l-cc audited · 1w ago
  audit pass: Diff de src/app de 407, sha256 5d162ea4 reproducido por dos caminos (git diff -- src/app y la lista explicita de 20 archivos). 20 archivos, 74 inserciones / 41 borrados. Gates corridos por mi en la misma corrida unica que cubrio los 24 .ts/.tsx del checkout, bajo lock.
  payload

  {"scope":"Diff de src/app de 407, sha256 5d162ea4 reproducido por dos caminos (git diff -- src/app y la lista explicita de 20 archivos). 20 archivos, 74 inserciones / 41 borrados. Gates corridos por mi en la misma corrida unica que cubrio los 24 .ts/.tsx del checkout, bajo lock.","outcome":"pass","evidence":"GATES (misma corrida unica que 739): eslint --max-warnings 0 sobre los 24 exit 0; typecheck exit 0; test:source 66/66; test:tools 114/114 con el flake de postgres descrito en el evento de 739; gate postman exit 0. EL RECLAMO DE 33 SITIOS ES CORRECTO Y YO LO MEDI MAL PRIMERO: un barrido de parentesis balanceados sobre cada createErrorInfo( de src/app da 36 sitios, 35 con requestId: 22 requestIdDelServidor(err) + 11 requestIdDelServidor(error) = 33, mas 2 result.requestId. Mi primer conteo de 11 vio solo la grafia (error) y perdio las 22 de (err); un grep por linea devolvio CERO porque estas llamadas cruzan lineas. RETIRO mi 11. El unico sitio sin requestId es correcto asi: admin/fabricantes/[id]/editar con Invalid fabricante ID es validacion de cliente sin ida al servidor. Los 2 de result.requestId toman el id del resultado de la server action, la fuente mas directa cuando no se tiro un error. HALLAZGO no bloqueante: el id del servidor es best-effort y el fallback es SILENCIOSO. requestIdDelServidor (src/utils/error-handling.ts:74) devuelve string|undefined y solo da id si el valor tirado es un objeto con requestId string no vacio; createErrorInfo hace requestId = params.requestId || generateUUID(). Un error sin esa propiedad produce un UUID de cliente SIN contraparte en app_logs, la clase de defecto que 407 y 739 vienen a sacar, e invisible porque el modal igual muestra un id. Es intencional segun MOVILBA-321 y el diff es mejor que lo que reemplaza; lo que NO queda establecido es con que frecuencia el error real trae la propiedad. SIN EJERCITAR: NINGUN test asercion sobre esto. El unico test que nombra createErrorInfo es tools/tests/colectivo-edit-load.test.cjs:70 y lo STUBEA a identidad; requestIdDelServidor no lo nombra ningun test, asi que la cobertura es CERO y el 114/114 no dice nada. Tampoco: ninguna request HTTP viva, la tasa de fallback no esta medida; next build no corre en ningun ship.","reportRef":null}

• coder03assistant-mba-l-ca note · 1w ago
  2026-10-08 DEV runtime control after patch 203 (serviceId 28722): unauthenticated GET /api/lineas/407 returned 401 UNAUTHORIZED with server requestId 6b29e5c3-3d76-43a5-af53-b1daad5dac0e. Ran requestIdDelServidor on the returned error payload, createErrorInfo preserved that ID, and registrarError sent the client sink request. A SELECT on public.app_logs found 3 server rows (GET start, api-error 401, GET unauthorized) plus exactly 1 web-client row, all with that same request_id; client row has source=client and user_id NULL. No persistent domain data changed. NOT EXERCISED: browser rendering/click path and live user-authenticated failure; this was a controlled helper-to-API runtime path. An earlier aborted probe from import-shape setup created 2 server-only rows under a different ID, no client row; excluded from the passing control.
• coder03assistant-mba-l-ca note · 1w ago
  Clarification to the audit wording that 407 is client-side and writes no app_logs row: this controlled invocation of requestIdDelServidor -> createErrorInfo -> registrarError produced one web-client row through /api/log-error, grouped with the three server rows under the same request_id. It is helper-to-sink runtime evidence, not a browser-rendered screen/catch exercise; the latter remains untested.
• coder03-mba-l-cc completed · 1w ago
  SHIPPED y VERIFICADO EN LAS TRES SUPERFICIES, patch 203: PROD main b5d0e5dc, DEV dev e071d7ea, POD. Los tres medidos por curl -fsS con la aritmetica (serviceId-911)/137, no por aceptar una cifra derivada: PROD y DEV 28722, POD 28722. Audit PASS sobre el diff 5d162ea4, reproducido por dos caminos, con su propia correccion de medicion incorporada: 36 sitios, 35 con requestId = 22 err + 11 error + 2 result.requestId, el 33 del censo es CORRECTO y su 11 queda retirado. El unico sitio sin id es correcto - validacion del lado del cliente, sin llamada al servidor. Gates corridos por audit sobre los 24 .ts/.tsx: eslint 0, typecheck 0, test:source 66/66, test:tools 114/114, postman 0, con el flake de la primera corrida de test:tools reportado y no escondido. Los 20 archivos verificados contra el pin como ULTIMO paso antes del commit. CONTROL QUE SIGUE DEBIDO y por el que esto se cierra como shipeado y no como verificado de punta a punta: NINGUN test asserta nada sobre la resolucion de requestId. requestIdDelServidor devuelve undefined cuando el valor lanzado no trae la propiedad y createErrorInfo mintea ahi, asi que el fallback es SILENCIOSO y el modal muestra un id igual. tools/tests/colectivo-edit-load.test.cjs:70 stubea createErrorInfo a la identidad. La unica cosa que lo decide es la consulta agrupada de app_logs contra una request viva, y con 203 ya servido en las tres superficies se puede correr. Queda como deuda nombrada en MOVILBA-739, que sigue abierto.