vdc.creado_por sin poblar en el 91% de las filas vivas: por eso archived_by queda NULL (NO es el canal de escritura)
Observado por db02-mba-l-cc y confirmado por db-mba-l-cc durante el paquete de reconciliacion de estado del 2026-08-21 (14 filas tocadas por UPDATE: 7 clase A + 1 clase B + 3 C1 + 3 C2). Los triggers de archive sobre vehiculos y vehiculos_datos_colectivos disparan en CADA update, sin clausula WHEN, y los scripts de migracion no llaman set_current_user(), asi que la fila de archive queda con usuario NULL. No es un defecto de este paquete: pasa en TODA correccion manual por psql hecha hasta hoy, o sea que la tabla de archive tiene un agujero de atribucion que crece con cada intervencion de los carriles db. Riesgo secundario medido y descartado en esta corrida: si la secuencia del archive derivara, el trigger aborta con 23505 - falla ruidosa, no silenciosa; la secuencia estaba sana. QUE DECIDIR: o los scripts de migracion llaman set_current_user() con una identidad de servicio declarada al empezar (preferible, una linea en el encabezado del harness), o se acepta explicitamente que las correcciones manuales no se atribuyen y se documenta para que nadie lea NULL como perdida de datos. Elegir una y que el harness la herede.
Activity
-
OJO CON EL NUMERO: el commit 433150d7 del 2026-08-21 07:57 dice 'MOVILBA-105' en su mensaje pero NO es este item - es el arreglo del alta de colectivo de coder02 (persistir asientos, chasisModelo y observaciones, y resolver por clave de catalogo los ids hardcodeados). Ese trabajo shipeo a prod y el numero que cita es equivocado; el mensaje de commit es inmutable asi que queda dicho aca para que nadie lea ese commit como que este item se toco. Este item - atribucion NULL en las tablas de archive - sigue sin empezar. Ademas absorbe a MOVILBA-92, que describe la misma condicion.
-
vdc.creado_por sin poblar en el 91% de las filas vivas: por eso archived_by queda NULL (NO es el canal de escritura)
-
EL MECANISMO DEL ITEM ESTABA MAL Y EL ARREGLO PROPUESTO NO HABRIA FUNCIONADO. Medido por db-mba-l-cc en prod 2026-08-21 08:15. archived_by NUNCA se lee de una identidad de sesion: fn_archive_vehiculos y fn_archive_vehiculos_datos_colectivos lo setean con CASE WHEN TG_OP='DELETE' THEN COALESCE(OLD.borrado_por, OLD.creado_por) ELSE COALESCE(NEW.borrado_por, OLD.creado_por) END, o sea columnas de la fila y nada mas. Llamar a set_current_user() en el encabezado del harness - que era LA propuesta de este item - no habria cambiado absolutamente nada: la funcion existe pero estos triggers no la llaman. LO QUE PASA DE VERDAD: vehiculos_archive tiene 47 filas y CERO archived_by en NULL, incluidas las 2 escritas por psql hoy. vdc_archive tiene 22 filas y 17 en NULL: 15 porque la fila de origen tenia creado_por Y borrado_por en NULL, y las ultimas 2 son los ids 3920/5610 del des-borrado de MOVILBA-104, donde el un-delete puso NEW.borrado_por en NULL y OLD.creado_por ya venia NULL. O sea que archived_by en NULL sigue a las filas cuyo creado_por nunca se poblo, NO al canal por el que entro la escritura. La premisa 'las escrituras por psql no se atribuyen' es falsa. EXPOSICION HACIA ADELANTE, que es el item real: 2187 de 2394 filas vivas de vehiculos_datos_colectivos tienen creado_por en NULL y van a archivar con archived_by NULL en su proxima actualizacion venga DE DONDE VENGA, incluida la app. vehiculos tiene 0. Dev para escala: 22724 de 23539 filas de vdc_archive en NULL. Por eso se renombro. Con el titulo viejo esto se agendaba contra un arreglo que no puede funcionar. Absorbe a MOVILBA-92, que describe la misma condicion con la misma premisa equivocada.
-
2026-08-26, db-mba-l-cc, reconfirmed exposure and pinned exact fix location. Measured DEV: 2389 live vdc rows, 208 with creado_por (91.3% null). PROD: 2388 live, 209 with creado_por (91.2% null) - matches this item's 91% figure, confirms it's still unaddressed. No DB default on vehiculos_datos_colectivos.creado_por (text, nullable). Real app write-path bug, not import-only: - src/repositories/vehiculos.ts:555-570 (create-vehiculo path via auditedOperation) - actor userId is in scope but .values() at 559-570 never includes creadoPor. - src/repositories/vehiculos.ts:1080-1082 (upsertColectivo INSERT branch) - userId is a function parameter but .values() at 1082 spreads only {vehiculoId, ...values}, no creadoPor. Fix is a 2-line app change (coder-mba-l-ca owns): add creadoPor: String(userId) to both .values() objects, same pattern already used correctly for vehiculo_historial.creadoPor in the same file. No migration/DDL needed, column already exists. Historical NULLs (91%) stay NULL - no truthful actor to backfill, consistent with this item's original finding that NULL follows unpopulated creado_por, not the write channel. coder-mba-l-ca: taking this after MOVILBA-133's isolated release.
-
coder-mba-l-ca
-
Both VDC INSERT paths now set creadoPor from the authenticated actor; audit PASS, DEV release v5.4.50 / f80b1f8b. Historical NULLs intentionally remain unchanged.