app_logs.status_code y error_code son NULL en todas las filas: no se puede filtrar por estado, y el cero no mide nada

Sub-tickets

Activity

• wi-cli-venus created · 7w ago
• wi-cli-venus priorityChanged · 5w ago
  2
• wi-cli-venus verified · 5w ago
  Re-medido el 2026-09-07 por db02 sobre DEV mientras se rastreaba el requestId 0abec334-28d9-4454-84f1-652205cb211b: status_code Y error_code son NULL en TODAS las filas recientes, no solo status_code. Amplia el titulo del item. La consecuencia operativa, que es lo que lo vuelve mas que cosmetico: NO SE PUEDE FILTRAR app_logs POR ESTADO. Un barrido de 'errores en la ultima hora' por status_code devuelve vacio siempre, asi que 'no hay filas de error' NUNCA se puede leer como 'no hubo errores'. Cualquiera que use esa consulta como control se lleva un cero que no mide nada - la forma de un_gate_sin_configurar_se_lee_igual_que_un_gate_que_paso. Levantado por audit-mba-l-cc como hueco de logueo independiente del incidente que lo destapo. Subido a P2.
• wi-cli-venus titleChanged · 5w ago
  app_logs.status_code y error_code son NULL en todas las filas: no se puede filtrar por estado, y el cero no mide nada
• wi-cli-venus completed · 5w ago
  Cerrado para el embudo del SERVIDOR, con evidencia medida por db02. NO cerrado como 'toda la tabla'. El log se movio a createErrorResponse, la unica funcion por la que pasan todas las respuestas de error y la que ya calcula el status que sale por la red, con statusCode y errorCode en el NIVEL SUPERIOR del data, que es donde logger.ts:204-205 los lee. CONTROL: error_code no-NULL en 3 de 3 filas nuevas contra 0 de 119392 previas. Ningun llamador anterior puede producirlo, asi que un valor ahi solo puede venir de este commit. status_code solo no habria servido como discriminador. PREMISA CORREGIDA, y es lo que hay que llevarse: status_code NUNCA fue inalcanzable por esquema. 30 filas pre-deploy lo tenian poblado, todas de src/lib/rendiciones-api.ts, el unico llamador que ya lo mandaba en el nivel superior -su propio comentario en :22-26 lo dice-. Lo inalcanzable era error_code, 0 de 119392. Las dos columnas tienen historias distintas y no se afirman juntas. Tambien se poblan desde el cliente (5.5.44): /api/log-error no las escribia y fijaba level:'error' a mano. Par antes/despues sobre el MISMO endpoint: 15:17:36 fila web-client con las dos columnas NULL (build viejo), 15:19:49 fila web-client con 418/CONTROL_329 (build nuevo). NO CUBIERTO: volumen de 4xx en uso real. Todas las filas post-deploy son sinteticas.