Los 13 archivos que no usan ningun helper de error: sin captura no hay id que correlacionar - forma distinta de 407, sin trazar
Done normal
rmresearcher-mba-l-cc
Researcher's 407 census (2026-10-08) found 13 files that touch NEITHER createErrorInfo() NOR requestIdDelServidor(). Spot-check of vehiculos/page.tsx: the error is discarded before capture and there is no log() call at all, so there is no id to correlate and no row to correlate it with - a different defect shape from 407's discard-and-mint, and NOT traced file-by-file. Filed separately so 407's fix does not silently claim coverage of it. Scope: census the 13, name per file whether the error is captured at all, and say which are genuine gaps vs screens with nothing to report.
Activity
-
parent=#3560
-
2026-10-08T16:30:56-03:00 / 19:30:56Z researcher-mba-l-cc. File-by-file trace of the 13 files flagged in 407 as "touches neither helper" (requestIdDelServidor/createErrorInfo) - this census does NOT reuse that grep's conclusion, it re-derives per catch block, since "touches neither shared helper" and "drops the server id" turned out NOT to be the same thing. CORRECTION to my own 407 note: 2 of the 13 are false flags, already correctly wired, just via code that doesn't call the two named helpers: - src/app/admin/fabricantes/agregar/page.tsx:53-66: `if (isApiError(error)) setErrorRequestId(error.requestId)`, only mints crypto.randomUUID() for the genuinely-non-ApiError branch. Correct. - src/app/lineas/agregar/page.tsx:88-92, 134-138 (2 sites): `const requestId = isApiError(err) ? err.requestId : undefined` passed straight into showError. Correct. Also REMOVED: src/app/vehiculos/[dominio]/editar/page.tsx has no catch block at all - the word "catch" in my 407 grep matched a Spanish code comment, not a real try/catch. Not part of this population. GENUINE drops, confirmed per catch block (no requestId extracted, no log() call either, so no row and no id reach anywhere) - 8 files, 14 call sites: - src/app/admin/audit-log/page.tsx:49-53 (1): isApiError checked for .message only. - src/app/admin/carrocerias/agregar/page.tsx:60-64, 126-130 (2): same shape, message only. - src/app/admin/opciones/[id]/page.tsx (3): first catch (89-99) logs with a client-minted PER-ATTEMPT requestId generated before the try block, not the error's own - so it DOES call log(), but correlates to the client's own retry-attempt id, never the server's, even when isConnectionError/isApiError. Second (156-159) and third (182-187) catches: showError(message) only, no id, no log() at all. - src/app/auth/verify-email/page.tsx:41-44 (1): bare `catch {}`, no error binding, generic message, no log(). - src/app/entidades/[id]/page.tsx:155-166 (404 check, message only), :292-294 (delete handler, console.error + generic message) (2). - src/app/reset-password/page.tsx:59-63, 102-106 (2): no isApiError check at all on either catch, no requestId, no log(). - src/app/user/login/LoginForm.tsx:212-215 (1): final catch, console.error + generic message, no log(). (The earlier branch at :206-210 in the same file is NOT a drop - it surfaces an id from logClientError(), a legitimately client-originated case with nothing server-side to lose.) - src/app/vehiculos/page.tsx:125, 142-146 (2): `.catch(() => {...})` with no bound error parameter - error discarded before any id question is reachable, no log() call. OUT OF SCOPE, not a server-communication failure path: src/app/admin/analisis-importacion/page.tsx:121-123 (bare catch around a clipboard-copy fallback, no network call in the try). src/app/admin/page.tsx:44-50 already correctly uses `error.requestId || 'admin-page'` when isApiError (the static-string fallback is a different, smaller issue - never mints a UUID, so it does not create an orphaned-pair row, just a non-id literal) - its second catch at :66 silently defaults a feature-flag, not user-facing. TOTAL for 741: 8 files / 14 call sites genuinely drop the server id with no log() call at all (distinct from 407's 33 sites, which DO call log()/createErrorInfo but mint instead of extract). 2 files were false flags (already correct). 2 files are out of scope for this defect class (no network call, or already correct with a different minor issue). UNEXERCISED: no DB/app_logs readback. Did not check whether isApiError(err).requestId can itself be empty/undefined at runtime for any of these call sites. Did not trace whether any of the 14 drop-sites' underlying endpoint is one of the service/repo paths coder04 is independently touching under 407's other half.
-
coder03-mba-l-cc 19:33Z - promoted; it is researcher's live work while 408's fix half and 740 wait on decisions.
-
2026-10-08T18:41:25-03:00 / 21:41:25Z researcher-mba-l-cc. Re-closing: this item's census was already fully posted at 19:31:25Z (same day) - status had fallen back to todo via a statusChanged flip-flop (mine then coder03's 'promoted' at 19:31:32Z), not because work remained. No new measurement needed; restating the shape per coder03's request. Of the 13 files 407 flagged as touching neither helper: 8 files/14 call sites are genuine drops (error caught, no requestId extracted, no log() call at all - distinct from 407's mint-instead-of-extract shape). 2 files were false flags (already correctly wired via isApiError without calling the two named helpers). 2 files are out of scope (no network call in the try, or already correct with an unrelated minor issue) - and one file from the original 407 grep (vehiculos/[dominio]/editar/page.tsx) is removed entirely: the grep hit was a Spanish comment containing the word catch, not a real catch block. 8+2+2=12 of the original 13; 13th removed as a false population member. Full per-file detail in the 19:31:25Z note on this item.
bug
1w ago by coder03-mba-l-cc
1w ago
2026-10-08 21:41