Un escritor de la UI creo filas de vehiculo_historial sin fecha de apertura, dos veces en agosto
Medido por db02-mba-l-cc el 2026-09-05 separando la subclase de 75 grupos con fecha_alta NULL de MOVILBA-283. De esas 75 filas (75 vehiculos distintos, una por vehiculo, 74 ya con borrado_en y solo UNA activa), 73 son 'system_import' y salen del lote de junio: 72 en una sola sentencia del 2026-06-22 10:50:32 y 1 del 2026-06-29 14:24:01. Las OTRAS DOS son escrituras de la UI hechas por cuentas de usuario reales, una el 2026-08-07 y otra el 2026-08-14. Esas dos son el defecto VIVO: un camino de usuario creo una fila de historial sin fecha de apertura. Misma familia que MOVILBA-281, que era la misma superficie escribiendo sin tramite_id. Una fila de historial sin fecha_alta no puede aparear nunca contra el libro por (dominio, fecha_alta), asi que es excedente por construccion y ningun import la va a reconciliar. Hay que encontrar el camino de la UI que lo permite y que fecha_alta sea obligatoria en el escritor, no solo en el formulario. ADVERTENCIA DE METODO, medida en el mismo trabajo: audit_log NO ES TESTIGO DE ESTA TABLA - consultado por table_name='vehiculo_historial' sobre esos 75 record_id devuelve CERO filas. El metodo 'probar la escritura de la UI por audit_log.details.valuesSet' que sirvio para 281 NO APLICA a vehiculo_historial. La unica procedencia que tiene esta tabla es creado_por, y por regla permanente creado_por afirma 'system_import' donde no sabe. NO EJERCITADO: no se abrieron los vehiculos de las dos filas de UI para ver que estaba haciendo el usuario; PROD sin medir para esta clase.
Activity
-
db02-mba-l-cc, 2026-09-05 09:08 - EL ITEM SE ACHICA PERO NO SE CIERRA. Las dos filas de UI con fecha_alta NULL son ESCRITURAS DE PRUEBA, no un camino de produccion fallando: id 5071 es el dominio ABC1234 con observaciones 'Alta de colectivo', id 9637 es AI396KI con observaciones 'test', escrita desde la cuenta del propio Elazar. O sea nadie choco con un flujo roto. El defecto SIGUE SIENDO REAL: el escritor ACEPTA una fila de historial sin fecha de apertura. Cambia la urgencia, no la existencia. Pista mas fuerte disponible: el payload de esas filas trae solo estadoId/entidadId/lineaId, sin ninguna clave de fecha ni de expediente, lo que apunta al camino de edicion de estado/linea/entidad y no a un formulario de alta - y es la mejor pista que hay porque audit_log no tiene nada para esta tabla. INCIDENTAL Y VALE LA PENA SABERLO ANTES DE TRATAR borrado_en COMO UN TIMESTAMP DE CICLO DE VIDA: la id 9637 lleva borrado_en 2026-08-04, DIEZ DIAS ANTES de su propio creado_en del 08-14. No es imposible - borrado_en es la Fecha Baja del libro y no una marca de borrado - pero es exactamente la clase de cosa que rompe una asercion que asume orden temporal.
-
db02-mba-l-cc, 2026-09-05 09:08 - EL ITEM SE ACHICA PERO NO SE CIERRA. Las dos filas de UI con fecha_alta NULL son ESCRITURAS DE PRUEBA, no un camino de produccion fallando: id 5071 es el dominio ABC1234 con observaciones 'Alta de colectivo', id 9637 es AI396KI con observaciones 'test', escrita desde la cuenta del propio Elazar. Nadie choco con un flujo roto. El defecto SIGUE SIENDO REAL: el escritor ACEPTA una fila de historial sin fecha de apertura. Cambia la urgencia, no la existencia. Pista mas fuerte disponible: el payload de cambios de esas filas trae solo estadoId/entidadId/lineaId, sin ninguna clave de fecha ni de expediente, lo que apunta al camino de edicion de estado/linea/entidad y no a un formulario de alta - y es la mejor pista que hay porque audit_log no tiene nada para esta tabla. INCIDENTAL Y VALE LA PENA SABERLO ANTES DE TRATAR borrado_en COMO UN TIMESTAMP DE CICLO DE VIDA: la id 9637 lleva borrado_en 2026-08-04, DIEZ DIAS ANTES de su propio creado_en del 08-14. No es imposible - borrado_en es la Fecha Baja del libro y no una marca de borrado - pero es exactamente la clase de cosa que rompe una asercion que asuma orden temporal.
-
coder-mba-l-cc
-
coder03-mba-l-cc / coder
-
coder04-mba-l-ca
-
Fixed by the shipped 349/637 date contract (5.6.166+): createColectivo rejects absent expediente dates and writes fechaAlta from that date; createHistorialRecord requires expediente+fechaExpediente and writes fechaAlta from fechaExpediente, with no CURRENT_DATE fallback. The changes are live on PROD, DEV and pod per 5.6.167 rollout. Historical test rows remain; no data rewrite was in scope.