Make user-visible error IDs match app_logs

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus statusChanged · 5w ago
  Deployed to DEV v5.5.118 (83f0bc78); audit PASS, lint and TypeScript passed, health/freshness passed. Positive control returned requestId 8bc20e33-7773-492b-babc-fac382949066 from harmless HTTP 401; awaiting raw app_logs receipt.
• wi-cli-venus verified · 5w ago
  DEV v5.5.119: explicit-ID branch verified from returned 38ce50b7-1c6d-4710-a62f-151d189657b8; DB stored same request_id plus differing transportRequestId. Fallback correction audited and static gates passed. Post-fix window has 0 NULL / 3 rows, but did not execute auth-signin or vehiculos-service omitted-ID callers, so fallback runtime verification remains pending a non-mutating login plus /vehiculos navigation; stakeholder is not being asked to run it.
• wi-cli-venus verified · 5w ago
  DEV v5.5.119 (f67d8a66): explicit-ID branch verified with HTTP 401 receipt 38ce50b7-1c6d-4710-a62f-151d189657b8; app_logs request_id matched and the differing transport ID was retained in data.transportRequestId. Audit PASS and deploy gates, health, and freshness passed. Omitted-explicit-ID fallback is code/audit verified but awaiting a browser path that exercises auth-signin or vehiculos-service.
• wi-cli-venus assigned · 4w ago
  coder-mba-l-cc
• 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:00:26 ART dev 7d299b6a; main 721b9eb8: explicit-request-ID branch previously matched DEV HTTP 401 with app_logs; omitted-ID fallback has not been exercised. Full user-visible-ID correlation requirement remains open.
• coder03-mba-l-cc assigned · 2w ago
  coder04-mba-l-ca
• coder04-mba-l-ca statusChanged · 1w ago
  2026-10-05 ART: Login attempt for the newly assigned DEV01 runtime checks did not authenticate; the prior DEV01_WRITE_* values returned to /user/login. No omitted-ID caller or app_logs receipt was exercised. Awaiting an authorized dedicated write-account key set; no retry with the failed credentials.
• coder04-mba-l-ca note · 1w ago
  2026-10-05 17:11 ART: DEV01_NOVAL_* positive-control and DEV01_AGENTWRITE_* logins both succeeded using the hydration-aware runner; normal authenticated page load produced no error receipt from an omitted-requestId caller. I did not manufacture a failure or submit invalid data, per the acceptance criterion requiring the next real error receipt. No user-visible requestId/app_logs pair could be measured in this run. Next: capture and correlate the next naturally occurring omitted-ID error; item remains open.
• coder04-mba-l-ca blocked · 1w ago
  No omitted-requestId error receipt occurred during legitimate authenticated DEV01 navigation. Acceptance explicitly asks for the next real error and forbids manufacturing a failure; no safe caller produced one. Next: correlate the next naturally occurring omitted-ID error modal with app_logs.
• coder03-mba-l-cc assigned · 1w ago
  researcher-mba-l-cc / solo
• researcher-mba-l-cc note · 1w ago
  2026-10-08T12:34:26-03:00 researcher-mba-l-cc Trace: handleApiError (src/lib/errors.ts:189) -> createErrorResponse (errors.ts:153) -> log() OLD signature -> DB insert at logger.ts:203-213. The insert NULLs request_id whenever !UUID_RE.test(requestId) (logger.ts:205). Finding 1 - originally-filed bug is fixed, not reachable today. All 42 API-route handleApiError callers (grep across src/app/api/**/route.ts) generate requestId via a local randomUUID() before calling it (spot-checked vehiculos/route.ts:21, lineas/route.ts:12,98, entidades/route.ts:14,101). log()'s OLD-signature branch (logger.ts:115-131) preserves that explicit id as-is; the AsyncLocalStorage transport id only lands in data.transportRequestId when it differs. createErrorResponse builds errorResponse.error.requestId from the same raw input shown to the browser. So for every current API-route error, the id in the browser modal and the id in app_logs.request_id are the same UUID - the 2026-09-09 fix holds and no live caller exercises the old mismatch path. Finding 2 - separate, real gap: internal log() calls pass a non-UUID literal in the requestId slot, so logger.ts:205 NULLs app_logs.request_id for that row. Grep (tool-results/bm32cmvlm.txt) lists dozens of sites: src/repositories/*.ts and src/services/*.ts pass literal 'repository'/'service' (or 'service' as fallback on requestId || 'service'); src/lib/rbac.ts, src/lib/password-expiration.ts, src/utils/connectionHandler.ts pass 'SYSTEM'/similar; src/actions/vehiculo-match.ts:105 passes literal 'suggestCatalogMatch'; src/actions/api-docs.ts:20 passes literal 'canViewApiDocs'; src/components/UserMenu.tsx and src/app/admin/page.tsx fall back to literals ('user-menu','admin-page') only when error.requestId is absent. Checked whether Finding 2 ever surfaces a mismatched id to a user: no. vehiculo-match.ts's suggestCatalogMatch returns null on error (no id returned to caller at all). api-docs.ts's canViewApiDocs returns a boolean. admin/page.tsx and UserMenu.tsx use error.requestId (a real UUID from the API response) when present, and only fall back to the literal for client-only errors that never reached the server - so there is no server-side app_logs row to mismatch against in that case either. Net: the ticket's premise (a user-visible id that doesn't match app_logs) is not currently reachable anywhere traced. The actual defect is narrower - these internal/service-layer log rows are permanently uncorrelatable (NULL request_id) even though nothing user-facing depends on them. Fix if wanted: stop overloading the OLD signature's requestId slot with a source label for non-request-scoped logs; use the NEW signature (log(level, message, data)) for all of these so context's real request id (or a generated UUID) lands instead of a literal.
• coder03-mba-l-cc unblocked · 1w ago
  cleared: No omitted-requestId error receipt occurred during legitimate authenticated DEV01 navigation. Acceptance explicitly asks for the next real error and forbids manufacturing a failure; no safe caller produced one. Next: correlate the next naturally occurring omitted-ID error modal with app_logs.
• coder03-mba-l-cc completed · 1w ago
  coder03 2026-10-08 12:52 ART: closed on researcher's trace - the original 2026-09-09 mismatch is unreachable, all 42 route handlers pass real UUIDs. Separate finding spun off because its premise differs: internal log() calls passing a literal label as requestId NULL out app_logs.request_id via UUID_RE, but no such path surfaces an id to a user.