logger.ts persists app_logs.user_id and ip_address as NULL on every row - unawaited Promise behind an any-typed require

Sub-tickets

Activity

• audit-mba-l-cc created · 1w ago
• coder03-mba-l-cc assigned · 1w ago
  coder04-mba-l-ca
• coder03-mba-l-cc note · 1w ago
  coder03-mba-l-cc 2026-10-08 17:22Z / 14:22 ART - asignado a coder04. Detalle que traigo del duplicado MOVILBA-736, ya cancelado. MEDICION EN PROD de audit, curva por mes: user_id 7749/8199 en feb, 1293/17552 en may, 10/23560 en jun, 0/4140 en sep, 0/401 en oct. ip_address sigue la misma curva. Data de e3057166 (2026-05-20). ARREGLO: shim async + await en src/lib/logger.ts:207. CONTROL, y es la parte que importa: una fila de app_logs POSTERIOR al arreglo que lleve user_id poblado. Un typecheck verde NO sirve como control - es exactamente lo que no vio el defecto durante cinco meses, porque el any del require() de :12 tapa que :6 declara retorno sincronico y :13 devuelve una Promise. El control tiene que ser una fila leida de la base, no un gate verde. NO es una regresion de MOVILBA-732: el defecto es anterior y 732 shipeo en v5.6.196 sin tocar esa rama.
• coder04-mba-l-ca statusChanged · 1w ago
  Code diff ready for audit: logger.ts getLogContext shim is async and awaits server context inside try/catch; DB metadata branch awaits it before inserting app_logs. Acceptance remains post-deploy authenticated request and a new app_logs row with non-NULL user_id (ideally ip_address), not merely typecheck. MOVILBA-732 shipped v5.6.196; this is pre-existing, separate.
• audit-mba-l-cc audited · 1w ago
  audit fail: MOVILBA-735 diff src/lib/logger.ts sha256 8d206b0f, 3 hunks: shim async, await serverGetLogContext, await at :207. Ran typecheck tree-wide, eslint on logger.ts+request-context.ts, test:source, two tsc shape controls, PROD app_logs census. SIN EJERCITAR: live HTTP request, real app_logs row.
  payload

  {"scope":"MOVILBA-735 diff src/lib/logger.ts sha256 8d206b0f, 3 hunks: shim async, await serverGetLogContext, await at :207. Ran typecheck tree-wide, eslint on logger.ts+request-context.ts, test:source, two tsc shape controls, PROD app_logs census. SIN EJERCITAR: live HTTP request, real app_logs row.","outcome":"fail","evidence":"FAIL. The await fix is correct and adds a real gate, but it makes two client-controlled headers reach the DB and nothing strips them.\n(1) FORGED user_id. proxy.ts:206 new Headers(request.headers) COPIES inbound headers; :210 sets x-user-id only if (newUserId); proxy.ts has no .delete() of x-user-id/x-client-ip/x-request-id/x-request-source (its only deletes are on the RESPONSE, :357-360 and :387-390), and requestHeaders is what is forwarded at :313 and :376. So after 735 an ANONYMOUS request carrying x-user-id:<any> persists that value to app_logs.user_id (text, no FK). The column is NULL today only because of the bug. coder04 acceptance control passes on a forged value too; it needs a negative leg - unauthenticated + forged x-user-id must persist NULL. Fix is in proxy.ts, outside the stated logger.ts-only scope.\n(2) inet throw -> logging blackout. ip_address is inet (drizzle/schema.ts:44); proxy.ts:143 takes x-forwarded-for[0] unvalidated. Measured on movilba_dev: \"not-an-ip\"::inet and \"\"::inet both ERROR invalid input syntax for type inet. The insert at logger.ts:208-231 .catch()s, dbCircuit.failures+=1, and at DB_CIRCUIT_THRESHOLD=3 opens DB_CIRCUIT_COOLDOWN_MS=5min for ALL db logging in that instance; one request emits >=3 lines so one bad header can reach 3. Blast radius is the whole row, not the IP field. NOT a legit-traffic break: PROD app_logs, 751 captured clientIp values, 253 distinct, 0 invalid per pg_input_is_valid. In-scope fix: net.isIP() guard to null in logger.ts.\nCONTROLS SEEN TO FAIL: pre-fix shape (sync-typed shim returning the Promise through require()) gives tsc rc=0 and runtime userId=undefined; post-fix shape gives TS2339 at the call site, rc=2 - typecheck now guards this class and runs on both ship paths.\nGATES on 8d206b0f: typecheck 0 errors tree-wide, eslint --max-warnings 0 rc=0, test:source 66 pass 0 fail. 17:35Z / 14:35 ART.\nNIT: :207 re-reads headers already read at :128/:140 - hoist ctx.","reportRef":null}

• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc, 17:37Z / 14:37 ART. Residual detail behind the FAIL. HISTORY - no guard was dropped. git show e3057166^:src/lib/logger.ts has the sync-typed shim at :6 and only two ctx reads, :114 and :123, both awaited; there is no DB-insert branch, so logger never wrote ip_address or user_id before e3057166. The populated months in PROD app_logs (2026-02 ip 8158/8199, uid 7749; 2026-03 ip 8226/8239, uid 7131) therefore came from a DIFFERENT writer, and the collapse after 2026-05 (2026-06 ip 24 and uid 10 of 23560; 2026-09 ip 1 uid 0 of 4140; 2026-10 ip 0 uid 0 of 401) is when this path became the writer and started inserting NULLs. That dates the user-visible symptom to the regression without claiming logger ever worked. WHY typecheck cannot be cited as evidence either way. Probe /scratchpad/probe735.ts reproduces the PRE-fix shape - a shim declared to return a plain object that returns the Promise obtained through require() - and tsc --noEmit --strict exits 0, then tsx prints "no-await userId = undefined". The require() any-type is what hid this for five months. Probe735b.ts reproduces the POST-fix shape with the await dropped at the call site and gets TS2339 at (9,14), rc=2. So the diff converts an invisible class into a compile error on a gate both ship paths run. That is the part of the diff that should be kept as-is. SPLIT SUGGESTION for coder03, not a verdict: finding (1) is a proxy.ts fix and a security item (forged provenance in an audit-adjacent table), not a logger item. 735 as scoped is "logger.ts only" and cannot carry it. Either 735 widens to include the header strip, or the strip gets its own item and 735 blocks on it - what must not happen is 735 shipping alone, because shipping it alone is what makes the forged value persist. Finding (2) is in scope for 735. CHAIN VERIFIED for the fix itself: proxy.ts:208-210 sets x-request-source / x-client-ip / x-user-id, request-context.ts:21-26 reads x-request-id / x-request-source / x-user-id / x-client-ip under await headers(), matcher at proxy.ts:423 covers every path except _next/static, _next/image and favicon.ico. app_logs.user_id is text (drizzle/schema.ts:43) so the header string fits with no cast; ip_address is inet (:44) which is where finding (2) bites. STILL SIN EJERCITAR after this verdict, and the FAIL does not change it: no live HTTP request was issued and no app_logs row was observed with a populated user_id. Dev servers are Elazar-only, so whoever runs the accepted build should capture both controls in one run - a row with non-NULL user_id from a REAL authenticated session, and a NULL user_id from an anonymous request carrying a forged x-user-id.
• coder04-mba-l-ca progress · 1w ago
  Audit FAIL correction: proxy.ts strips caller-supplied x-user-id/x-client-ip/x-request-id/x-request-source before installing proxy-derived context; node:net.isIP gates x-client-ip to avoid invalid inet inserts and circuit-breaker blackout. logger.ts retains async shim and await at DB metadata branch. Two-file diff sent to audit. Post-deploy controls: authenticated request yields app_logs.user_id non-NULL; anonymous request with forged x-user-id yields NULL; malformed x-forwarded-for does not suppress DB logging.
• audit-mba-l-cc audited · 1w ago
  audit pass: MOVILBA-735 re-verdict, two files: src/lib/logger.ts sha256 8d206b0f unchanged, src/proxy.ts sha256 2aba263e (+7/-1). Ran typecheck tree-wide, eslint on both, test:source, a copied-lines strip control, and isIP over 253 distinct PROD client IPs. SIN EJERCITAR: live HTTP request, real app_logs row.
  payload

  {"scope":"MOVILBA-735 re-verdict, two files: src/lib/logger.ts sha256 8d206b0f unchanged, src/proxy.ts sha256 2aba263e (+7/-1). Ran typecheck tree-wide, eslint on both, test:source, a copied-lines strip control, and isIP over 253 distinct PROD client IPs. SIN EJERCITAR: live HTTP request, real app_logs row.","outcome":"pass","evidence":"PASS. Both of my 17:33:43Z FAIL items are closed, each with a control seen to fail against the prior bytes.\nSTRIP. proxy.ts:208-210 deletes x-request-id, x-request-source, x-user-id and x-client-ip from the copied Headers before the conditional sets. Control (7 lines copied verbatim into a scratchpad probe, loop toggled): with the loop OFF an ANONYMOUS request carrying x-user-id:VICTIM-42 and x-client-ip:9.9.9.9 keeps both; with it ON both read null, and a legit \"203.0.113.7, 10.0.0.1\" still yields 203.0.113.7. Shape control on copied lines, NOT an executed proxy().\nINET. proxy.ts:144-147 wraps the XFF/x-real-ip pick in isIP(), so \"\" is forwarded for a malformed value and the if (ipAddress) gate drops the header - inet never receives it and the breaker cannot be opened from a header. No legit-traffic regression: 0 of 253 distinct clientIp values in PROD app_logs are rejected by node isIP, and 0 are the IP:port, bracketed or zone-id forms isIP refuses.\nCORRECTION to my own FAIL: x-request-id was never forgeable - :207 sets it unconditionally, so the inbound value was always overwritten. The delete is defensive there, not a fix. The two real items were user_id and ip_address.\nSIDE EFFECT, credit direction, NOT measured: rate-limiter.ts:24 reads x-client-ip FIRST, so the health bucket at proxy.ts:159 and the login limiter via auth.ts:152 now key on a validated address instead of a client-declared one, and every malformed-XFF caller collapses into one health:unknown bucket - a tightening, not a loosening.\nGATES: typecheck 0 errors tree-wide, eslint --max-warnings 0 rc=0 on both files, test:source 66 pass 0 fail. 17:53Z / 14:53 ART.\nNOT closed by this PASS: no live request, no app_logs row observed. Post-ship needs BOTH legs - authenticated yields non-NULL user_id, anonymous with forged x-user-id yields NULL. The 253 IPs are external API callers; the health monitor XFF shape is unmeasured.","reportRef":null}

• coder03-mba-l-cc note · 1w ago
  coder03-mba-l-cc 2026-10-08 17:55Z / 14:55 ART - SHIPPED v5.6.199. dev 435a9e0a, main mergeado, DEV y PROD sirviendo patch 199 (sonda del propio deploy, 1/15 en prod). Pod: trigger 202 aceptado, todavia en 196, Tekton buildeando. Las dos patas van en UN commit a proposito: el strip de cabeceras y el await no se pueden separar por un limite de release, porque arreglar el await solo habria hecho persistir un user_id FORJADO en cada request anonima que mandara la cabecera. No hay item separado para el strip; no quedaba nada que archivar. Verifique los dos PASS contra el arbol antes del push, no los acepte del DM: logger.ts 8d206b0f y proxy.ts 2aba263e, los dos identicos al pin del evento audited de 17:38:12Z. GATE QUE NINGUN CAMINO DE SHIP CUBRE, medido por mi: audit corrio typecheck, eslint y test:source, y ninguno de los tres compila el entry del proxy. Ningun camino de ship corre next build. Entonces el nuevo import de node:net en proxy.ts habria sido fatal en el runtime edge y ningun gate lo habria visto. Lo resolvi contra el codigo de Next en vez de buildeando: node_modules/next/dist/build/analysis/get-page-static-info.js:609 dice textual 'Proxy always runs on Node.js runtime' y :616 tira E1031 si un archivo de proxy declara cualquier runtime. El import es valido. Queda registrado que lo salvo el runtime, no un control. SIN EJERCITAR: ninguna request HTTP viva, ninguna fila de app_logs observada. proxy-mba-w-cc tiene el gate cumplido (PROD en 199) y corre las DOS patas en una sola pasada - autenticado da user_id no NULL, anonimo con x-user-id forjado da NULL. La segunda es la que prueba el strip; sin ella la primera pasa igual sobre un valor forjado. El item queda abierto hasta esa medicion. El deploy lo bloquearon dos veces los archivos en vuelo del carril assistant (dropdowns route + page de colectivo rompen colectivo-edit-load.test.cjs: 16/16 pass parkeados, 2 fail puestos). Los parkee, shipee, y los devolvi byte-identicos contra copias que tome antes.
• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc, 18:00Z / 15:00 ART. POST-SHIP, measured on PROD app_logs, read-only. Two of the three open controls are now closed by real traffic rather than by a probe. STEP CHANGE AT THE DEPLOY BOUNDARY. main c18bf765 committed 2026-10-08 14:45:49 -0300 (dev 435a9e0a 14:44:12), app.movilba.com /api/health returns 200 with serviceId 28174. app_logs by minute over the last 30h: 11:19 6 rows ip 0, 11:33 6/0, 11:47 9/0, 11:49 2/0, 11:51 8/0, 11:52 30/0, 12:35 6/0, 13:14 6/0 - then 14:50 3 rows ip 3, 14:51 6 rows ip 6. Every row before the deploy has ip_address NULL and every row after has it populated (host 10.105.3.14, the internal front-proxy address). 9 of 9 post-deploy rows. That is the await fix working end to end on rows the app wrote itself, which is what neither typecheck nor my shape probes could show. ANONYMOUS LEG OF THE ACCEPTANCE CONTROL: PASSES. The three post-deploy requests are 401s on GET /api/entidades ("Unauthorized access attempt", "401 UNAUTHORIZED") and all nine rows carry user_id NULL while ip_address is populated. So the column is reachable and an unauthenticated caller still gets NULL - the forged-identity failure mode my FAIL described cannot now be read as "untested". AUTHENTICATED LEG: STILL OPEN. No authenticated request has reached PROD since 14:45:49, so user_id has not yet been observed non-NULL from a real session. Note the pre-fix rows at 13:14 include "Login successful" and "User login successful" with user_id NULL, which is the old behaviour and not evidence about the new bytes. Whoever next logs in to app.movilba.com closes this with one query: select user_id, host(ip_address) from public.app_logs where created_at > now() - interval 5 minute and user_id is not null. NOT MY REQUEST. The 14:50-14:51 traffic is not the curl I issued - mine was /api/health, these are /api/entidades. I did not generate the evidence I am citing; it is ordinary PROD traffic that happened to cross the boundary, which is why the before/after is credible.
• coder04-mba-l-ca progress · 1w ago
  PROD v5.6.199 runtime control: anonymous forged-header GET /api/entidades?limit=1 with x-user-id:VICTIM-42 and x-client-ip:9.9.9.9 returned 401, requestId 703a8f24-bf23-4fcc-a084-4bd1216eae36 at 2026-10-08 17:51:08 UTC. db04 is checking its app_logs row read-only. Authenticated leg is pending Elazar login in the proxy PROD browser, which currently redirects to /user/login; proxy does not enter credentials. Item remains open until non-NULL user_id and cross-layer correlation are observed after patch 199.
• db04-mba-l-ca progress · 1w ago
  db04 SELECT-only PROD patch-199 runtime control for proxy's anonymous forged-header requestId 703a8f24-bf23-4fcc-a084-4bd1216eae36 (401 at 17:51:08 UTC): 3 app_logs rows matched request_id directly, 0 via transportRequestId; all user_id NULL, 0 forged VICTIM-42, 0 forged 9.9.9.9 ip_address, all 3 ip_address non-NULL. Sources: GET /api/entidades (2), api-error (1), final 401. Anonymous negative leg PASS; authenticated non-NULL user_id and cross-layer correlation NOT EXERCISED because proxy lacks an authorized PROD session. Evidence/query: /data-lezama/movilba/evidencia/MOVILBA-735/2026-10-08-prod-anonymous-forged-header-runtime-control.md. No DB write.
• coder03-mba-l-cc note · 1w ago
  coder03-mba-l-cc 2026-10-08 18:00Z / 15:00 ART - FLEET PARITY en patch 199, las tres superficies medidas en una sola pasada: app.movilba.com serviceId 28174, dev01 127.0.0.1:3042 serviceId 28174, pod permisos-movilba-dev.gcba.gob.ar serviceId 28174. (28174-911)/137 = 199 exacto en las tres. main c18bf765 verificado con git rev-parse, no citado de un DM. El pod tardo ~11 minutos desde el 202, mas que los 3-4 que anuncia el script, y llego solo - no hubo build zombie y no hizo falta token de OCP. PATA ANONIMA CERRADA SOBRE FILAS PERSISTIDAS, no sobre el 401. Yo habia marcado que un 401 no es la medicion y que el riesgo real era que NO existiera fila, porque una fila ausente se lee como pass. Medido independientemente por audit y por db04 y coinciden: el requestId 703a8f24-bf23-4fcc-a084-4bd1216eae36 tiene TRES filas en app_logs (2 de route, 1 de api-error/401), las tres con user_id NULL, las tres con ip_address poblado, CERO iguales al forjado 9.9.9.9. Evidencia en /data-lezama/movilba/evidencia/MOVILBA-735/2026-10-08-prod-anonymous-forged-header-runtime-control.md. Y el control se vio FALLAR contra el comportamiento anterior, que es lo que lo vuelve un control y no una linea verde: censo de audit por minuto cruzando el limite del deploy (main c18bf765, 14:45:49 -0300) - 11:19 6 filas ip 0, 11:33 6/0, 11:47 9/0, 11:51 8/0, 11:52 30/0, 12:35 6/0, 13:14 6/0, y despues 14:50 3 filas ip 3 y 14:51 6 filas ip 6. Todas las anteriores con ip_address NULL, las 9 posteriores pobladas. FALTA la pata autenticada: ninguna sesion toco PROD desde las 14:45:49. Pide el login AD de Elazar en el browser del proxy. Las filas pre-fix de 13:14 incluyen 'Login successful' con user_id NULL, asi que el contraste va a ser inequivoco. El item NO se cierra hasta esa fila.
• coder04-mba-l-ca blocked · 1w ago
  Only remaining acceptance leg requires Elazar to log into the PROD browser used by proxy. PROD v5.6.199 anonymous forged-header control is proven on three persisted app_logs rows (all user_id NULL, real IP, none 9.9.9.9), and post-deploy IP logging is restored. Authenticated request must yield a persisted non-NULL user_id and route/service/repository requestId chain. PM requested Elazar login; no agent enters his AD credentials.
• coder04-mba-l-ca progress · 1w ago
  PROD v5.6.199 authenticated runtime control, SELECT-only: proxy GET /api/vehiculos?page=1&pageSize=1 at 2026-10-08T18:01:54Z returned requestId 6767bd3e-8176-435c-b6b0-0fd5c4058ef3 for Elazar account 20247094211. app_logs has 13 rows for that UUID: 13/13 user_id=20247094211, 13/13 ip_address non-NULL, 0 NULL user IDs, 1 distinct request_id. Sources are GET /api/vehiculos, vehiculos-service, vehiculo-repository. Anonymous forged-header leg separately has three persisted rows, all user_id NULL, no forged 9.9.9.9 (evidence /data-lezama/movilba/evidencia/MOVILBA-735/2026-10-08-prod-anonymous-forged-header-runtime-control.md). Proxy also ran same authenticated route on DEV01 and pod patch 199.
• coder04-mba-l-ca unblocked · 1w ago
  cleared: Only remaining acceptance leg requires Elazar to log into the PROD browser used by proxy. PROD v5.6.199 anonymous forged-header control is proven on three persisted app_logs rows (all user_id NULL, real IP, none 9.9.9.9), and post-deploy IP logging is restored. Authenticated request must yield a persisted non-NULL user_id and route/service/repository requestId chain. PM requested Elazar login; no agent enters his AD credentials.
• coder04-mba-l-ca completed · 1w ago
  Done. Audited two-file fix live on PROD, DEV and pod v5.6.199. Authenticated PROD request wrote 13 app_logs rows with matching account user_id and populated IP; anonymous forged-header request wrote three rows with NULL user_id and no forged IP. Both positive and negative runtime legs measured.
• db04-mba-l-ca progress · 1w ago
  db04 SELECT-only PROD patch199 authenticated runtime control: proxy GET /api/vehiculos?page=1&pageSize=1 requestId 6767bd3e-8176-435c-b6b0-0fd5c4058ef3. current_database()=movilba; 13 app_logs rows, 13/13 user_id equals the one active users row for Elazar's signed-in account, 13/13 ip_address non-NULL, 0 NULL/wrong user, 1 distinct request_id. Sources: route 8, vehiculos-service 4, vehiculo-repository 1, all on that UUID. Together with prior anonymous forged request (3 rows, all user NULL, forged IP 0), both PROD acceptance legs now PASS. Exact query and scoped caveats: /data-lezama/movilba/evidencia/MOVILBA-735/2026-10-08-prod-authenticated-three-layer-runtime-control.md. No DB write; pod/DEV01 app_logs not independently checked.
• db04-mba-l-ca progress · 1w ago
  Secondary fleet confirmation after PROD PASS: SELECT-only movilba_dev app_logs for proxy's pod and DEV01 authenticated GET /api/vehiculos requestIds. Each ID has exactly 13 rows: route 8/service 4/repository 1; 13/13 user_id matches the same active Elazar account, 13/13 ip_address non-NULL, zero NULL/wrong user, one distinct request_id. Both surfaces share movilba_dev, so this is behavior confirmation, not independent database evidence. Evidence updated: /data-lezama/movilba/evidencia/MOVILBA-735/2026-10-08-prod-authenticated-three-layer-runtime-control.md. PROD remains the acceptance result. No DB writes.
• audit-mba-l-cc audit-finding · 1w ago
  MOVILBA-735 - COVERAGE STATEMENT on the PROD acceptance legs. audit-mba-l-cc, re-measured independently against PROD, SELECT-only, 18:1xZ / 15:1x ART. CONFIRMED, not accepted. I ran my own query rather than taking db04/coder04 numbers. requestId 6767bd3e-8176-435c-b6b0-0fd5c4058ef3: 13 rows, 1 distinct user_id = 20247094211, 0 rows with user_id NULL, 0 rows with ip_address NULL, 3 distinct sources (GET /api/vehiculos, vehiculos-service, vehiculo-repository), 0 transportRequestId breadcrumbs, window 15:02:23.651 to 15:02:23.783 -03. users WHERE id=20247094211 returns exactly 1 row, is_active true, last_login 14:59:49.054-03 - so the pass criterion is EQUALITY to the single active account row, not non-NULL. Anonymous forged leg: 3 requestIds at 14:50:51 / 14:51:04 / 14:51:08, 3 rows each, 9 of 9 with user_id NULL, no forged IP. UNEXERCISED - dev01 and the pod at the DATABASE level. Nothing was queried in movilba_dev. The three-surface claim rests on PROD rows plus two requestIds captured from the proxy with no DB read behind them. Do not read "all three surfaces" as measured: PROD is measured, dev01 and pod are inferred from the patch number and a captured id. The outstanding query is the two ids 3c1cac8c-f7ae-4bb9-9eea-48ff9e7c64bc and 51d2782e-7d90-4db7-89ce-0b187dc2564c resolved in movilba_dev, and it is only ONE query if the pod DATABASE_URL really targets movilba_dev - that lives in the Secret, not the ConfigMap, and must be read before assuming it. Sequenced after MOVILBA-461; completeness, not a blocker. NEW, and it bounds what the fix proved - the persisted IP is the INTERNAL HOP, not the caller. All 108 app_logs rows written since the deploy carry ip_address = 10.105.3.14, one single value, and the single row whose payload also carries clientIp carries the same 10.105.3.14. So "ip_address populated" is true and measured, but NOT ONE observed row distinguishes two callers, and the isIP() guard has never rejected anything live - every real value so far is a valid private address supplied by the ingress. The column is populated; its forensic value is unproven. Separately: the 253 distinct clientIp values I counted earlier came from a different field on a different path and are not evidence about this column. LOGIN LEG, request_id NULL - by design, and the fallback was OBSERVED working. Exactly 2 of the 108 post-deploy rows have request_id NULL: auth-signin "User login successful" and auth-jwt "New session created with refresh token", both 14:59:49. Cause is in the source, not the deploy: src/lib/auth.ts:685 and :424 call the OLD 5-arg signature with the LITERAL string "SYSTEM" as requestId, that literal is truthy so it beats ctx.requestId in logger.ts:129, and UUID_RE rejects it at logger.ts:212, so the column stores NULL. Both rows DO carry data->>transportRequestId = 5f50710f-80f1-44bc-86f5-169f0ebfcda6, the login POST, so correlation is recoverable from the payload - this is the designed breadcrumb branch seen firing on real rows for the first time. user_id NULL on those two is also correct: at login time the proxy had no x-user-id to install; the account is recoverable as data->>userId = 20247094211. Historical scale of the literal: 10345 rows with request_id NULL since 2026-05-21, 9400 of them auth-jwt. That is MOVILBA-732 residue, belongs there, and is not a 735 defect. NOT MEASURED BY ME at all: pod and dev01 app_logs rows; any non-JSON error or 500 path; the circuit breaker opening; a malformed x-forwarded-for reaching a live PROD request.
• db04-mba-l-ca progress · 1w ago
  Coverage correction to 18:10Z audit-finding: DEV DB leg was already SELECT-queried and recorded by db04 in the 18:06:06Z progress event, not unexercised. Re-ran now against current_database()=movilba_dev for proxy's pod and DEV01 requestIds in 18:00-18:06Z: each 13 persisted app_logs rows (route 8/service 4/repository 1), 13/13 user_id equals the single active signed-in account, 13/13 IP populated, 0 NULL/wrong user, 1 primary request_id. This establishes persisted behavior for both IDs in movilba_dev; it does NOT verify the live pod Secret DATABASE_URL target. oc whoami/get deployment from this host returned Unauthorized, no Secret value read. Evidence updated: /data-lezama/movilba/evidencia/MOVILBA-735/2026-10-08-prod-authenticated-three-layer-runtime-control.md. PROD acceptance remains PASS; Secret config check is separate completeness gap.
• audit-mba-l-cc audit-finding · 1w ago
  MOVILBA-735 - AMENDMENT to my coverage statement, plus a WITHDRAWAL of one of my own claims. audit-mba-l-cc, re-measured SELECT-only, 18:3xZ / 15:3x ART. 1. "dev01 and pod UNEXERCISED at the database level" is WRONG and I withdraw it. db04 had already queried movilba_dev; I re-ran it myself rather than take the correction on faith. current_database()=movilba_dev. requestId 3c1cac8c-f7ae-4bb9-9eea-48ff9e7c64bc: 13 rows, 1 distinct user_id = 20247094211, 0 user NULL, 0 ip NULL, sources GET /api/vehiculos + vehiculos-service + vehiculo-repository, 0 transportRequestId breadcrumbs, t0 15:02:32.980 -03. requestId 51d2782e-7d90-4db7-89ce-0b187dc2564c: identical shape, t0 15:02:53.916 -03. So all THREE surfaces are measured at the database level, not inferred from the patch number. What remains open is narrower and is a different question: WHICH of the two ids was the pod and which was dev01 rests on the proxy lane report, because both resolve in the same base and nothing in app_logs distinguishes the caller. The pod Secret DATABASE_URL was not read (oc Unauthorized). The fact that a row carrying the pod-attributed id exists in movilba_dev is itself evidence the pod writes there; it is not proof of what the Secret names. 2. WITHDRAWN: "the persisted IP is the internal hop, not the caller". That was a one-source sample and I should not have generalised it. All 108 post-deploy app_logs rows carry 10.105.3.14 because ALL of today traffic came from one place - the proxy agent egress - and pre-deploy app_logs has no IP distribution to compare against, since the column was NULL throughout. That is exactly the bug 735 fixed, so there is no before. The correct denominator is login_attempts, which has recorded extractClientIp since 2026-04-01 and whose first choice is the same x-client-ip header: 805 attempts, 270 DISTINCT ip_address, 0 NULL, spanning 2026-04-01 22:57 to 2026-10-08 13:14 -03. So the first XFF hop DOES vary per caller, and 10.105.3.14 appears there with exactly 3 attempts, 0 failures, 1 email - it is the proxy agent, not a universal hop. The column is useful; my earlier sentence was not. 3. UNCHANGED and still correct: the 2 request_id NULL rows are auth.ts passing the literal "SYSTEM" through the old 5-arg signature (:424, :469, :503, :546, :624, :651, :685, :693), truthy at logger.ts:129 and rejected by UUID_RE at :212; 10345 such rows since 2026-05-21, 9400 auth-jwt. Both carry transportRequestId 5f50710f-80f1-44bc-86f5-169f0ebfcda6 so they are correlatable from the payload. Recorded on MOVILBA-732. 4. NOT MEASURED BY ME at all, unchanged: any non-JSON error or 500 path; the dbCircuit opening; a malformed x-forwarded-for reaching a live request on any surface; the pod Secret.
• audit-mba-l-cc audit-finding · 1w ago
  audit-mba-l-cc 2026-10-08 20:38Z - SEVERITY CORRECTION to my own 743 FAIL evidence, raised by coder03 and verified by me against the scripts. WHAT I GOT WRONG: I wrote that neither deploy script runs test:tools and that 9a7e3119 would therefore have shipped PROD silently red. Both halves are wrong. Measured by grep on the scripts themselves: mba-deploy-dev.sh:178 runs pnpm run test:tools gated with exit 1 (stage label test:tools, step 1b/5), and mba-deploy-prod.sh:61 runs it the same way (step 2b/7). Both carry the comment MOVILBA-573: deploy runs both test suites explicitly. So the deploy would have ABORTED at that stage. The break was real, the FAIL stands on the control, but it was never silent and the audit gate was not the only place it was reachable. A SECOND STALE CLAIM I HAVE BEEN REPEATING, found while checking the first: mba-deploy-prod.sh:62 runs pnpm run build (step 2c/7). So a ship path DOES run next build. I have asserted "no ship path runs next build" in several earlier verdicts - including the logger/proxy reasoning on MOVILBA-735, where I used it to argue that a node:net import could not break the build. That conclusion survives on its own merits but the premise I cited for it is false, and the premise is what mattered. Every earlier verdict of mine carrying that sentence is corrected here. ROOT CAUSE OF BOTH: the repo CLAUDE.md section "What each ship path actually runs" lists dev as test:source + scoped lint + typecheck and prod as lockfiles + typecheck + test:source, omitting test:tools from both and build from prod, and adds "neither calls pre-commit, so lint:strict runs on no ship path at all". I took that table as the measurement instead of reading the scripts, which is exactly the instrument trap this project warns about - a written convention losing to the primitive. coder03 owns the CLAUDE.md fix. The lint:strict half of that sentence I have NOT re-verified and am not asserting either way.