7 vehiculos con estado contradictorio entre la ficha (BAJA) y la ultima fila de historial (ALTA), identicos en DEV y PROD

Sub-tickets — 1/1 done

Activity

• wi-cli-venus created · 7w ago
• wi-cli-venus note · 7w ago
  CORRECCION DEL SPLIT (db02-mba-l-cc, senialado por coder02-mba-l-cc y re-medido): la descripcion dice 'cinco ... y tres', que suma 8 sobre una lista de 7. Es 4+3. Lote 2026-06-22 10:50:32.25576 = AE060XC, AE631MI, PON576, PQP070 (4). Lote 2026-08-05 16:12:42.386728 = AI357EF, AI357EG, AI357EH (3). El error era mio al escribir, no en los datos: los 7 dominios listados siempre fueron 7. La lectura de lotes se REFUERZA con el split corregido - el segundo lote son tres dominios consecutivos (EF/EG/EH), todos linea 71 entidad 54, escritos en una sola sentencia: es una tira de patentes cargada junta, no tres ediciones independientes. PENDIENTE antes de concluir que el lado historial es el que miente: PROD y DEV coinciden al microsegundo en los 7, o sea que quien los escribio escribio UNA vez y se propago; descartar al importador exige descartarlo en el origen, no en un solo entorno.
• wi-cli-venus descriptionChanged · 7w ago
  was: 7 vehiculos tienen ESTADO CONTRADICTORIO entre sus dos fuentes: la ficha del colectivo (vehiculos_datos_colectivos.estado_id, que es lo que muestra la UI y lo que sirve v_vehiculos_detalle) dice BAJA, y la ultima fila de historial (v_vehiculos_hist_ultimo.estado_id, que es lo que sirve v_vehiculos_lineas_entidades) dice ALTA. Mismos 7 en DEV y en PROD, medido 2026-08-28 por db02-mba-l-cc. Dominios: AE060XC (linea 22, entidad 51), AE631MI (72/49), AI357EF (71/54), AI357EG (71/54), AI357EH (71/54), PON576 (20/49), PQP070 (131/65). Cinco fueron asignados el 2026-06-22 10:50:32.25576 y tres el 2026-08-05 16:12:42.386728 - dos lotes, no 7 accidentes sueltos. Aparecio validando el contrato de la API de Rendiciones: el cross-tab completo DEV es 1425 ALTA/ALTA, 772 BAJA/null, 178 ALTA/null, 11 BAJA/BAJA, 7 BAJA/ALTA. NO es un problema del documento ni de la API - coder02-mba-l-cc lo separo correctamente y me paso el item. Importa por la regla de custodio perfecto: un vehiculo dado de baja que una vista devuelve como alta es exactamente la clase de diferencia que hay que poder explicar antes de jubilar el Excel. PENDIENTE DE DECIDIR cual de las dos fuentes es autoritativa antes de tocar un solo dato; no hay GO y no se escribe nada hasta tenerlo.
• wi-cli-venus priorityChanged · 6w ago
  0
• wi-cli-venus note · 6w ago
  Elevado a prioridad 0 = espera decision de Elazar (convencion propuesta 2026-08-31). Lo que hace falta decidir: CUAL de las dos fuentes de estado es autoritativa. vdc.estado_id (la ficha, completa, lo que ve el usuario) o v_vehiculos_hist_ultimo.estado_id (derivada del historial, incompleta). La que pierda se REESCRIBE para 7 vehiculos en PROD, asi que el GO tiene que nombrar la fuente ganadora, no decir 'arreglen 147'.
• wi-cli-venus note · 6w ago
  Tres vehiculos mas con desacuerdo entre las dos fuentes de estado, medidos en PROD 2026-08-31 (db02-mba-l-cc, SELECT): PQP070, AE060XC, AE631MI. Hoy v_vehiculos_hist_ultimo dice 116 (ALTA) y la ficha (vehiculos_datos_colectivos.estado_id) dice 117 (BAJA). La fila de historial que la vista elige en cada caso es una fila viva; las filas del periodo cerrado estan ocultas con borrado_en (ver MOVILBA-167 nota del mismo dia). Si esas filas se des-ocultaran, la vista elegiria otra fila y el estado derivado pasaria a NULL en los tres - es decir, el historial dejaria de contradecir a la ficha en lugar de contradecirla al reves. Dato relevante para la decision de 147: el 60 por ciento de vehiculo_historial.estado_id ya es NULL, asi que 'el historial no opina' es el caso normal, no la excepcion. No tocar ninguno de los tres hasta que 147 defina cual fuente manda.
• wi-cli-venus note · 6w ago
  CORRECCION a la nota anterior de hoy (db02-mba-l-cc, 2026-08-31): PQP070, AE060XC y AE631MI NO son casos adicionales, son un SUBCONJUNTO de los 7 que este item ya cubre. Set completo re-medido en PROD hoy, historial 116 vs ficha 117: AE060XC, AE631MI, AI357EF, AI357EG, AI357EH, PON576, PQP070. Siguen siendo 7, no 10. Lo que si aporta la medicion: des-ocultar los periodos cerrados (ver MOVILBA-167) resolveria 3 de los 7 solo - los tres nombrados arriba pasarian a estado derivado NULL y dejarian de contradecir a la ficha. Los otros 4 (AI357EF, AI357EG, AI357EH, PON576) NO se mueven: su contradiccion vive en una fila viva y sobrevive a cualquier cambio de visibilidad. O sea que 147 no se resuelve solo por arreglar 167, y la pregunta de cual fuente manda sigue siendo necesaria para al menos 4 vehiculos.
• wi-cli-venus statusChanged · 6w ago
• wi-cli-venus note · 6w ago
  MEDIDO HOY 2026-09-03 en PROD (10.78.42.168, PG17.6) y DEV (10.9.10.54, PG15.17), SELECT, db02-mba-l-cc. La pregunta 'cual fuente es autoritativa' NO necesita decision: el LIBRO la contesta. LIBRO VIGENTE 2026-09-03-1049 (md5 b9880577fb9d886bfca4aaadba124ea5, 5368 filas de datos): los 7 dominios tienen CERO filas abiertas. LIBRO = BAJA en 7 de 7. La FICHA (vdc.estado_id=117 BAJA) coincide con el libro en 7/7; la superficie derivada del historial (116 ALTA) lo contradice en 7/7. Misma respuesta contra el libro del 09-01. La ficha gana por medicion, no por criterio. Y EL PLANTEO DE 'DOS FUENTES QUE SE CONTRADICEN' ES EQUIVOCADO. Las 7 filas vivas de historial YA tienen la fecha_baja correcta del libro: AE060XC 2026-08-07, AE631MI 2026-08-10, AI357EF/EG/EH 2026-08-13, PON576 2026-08-20, PQP070 2026-08-07. Los datos estan bien. Lo que esta mal es que esas filas llevan estado_id=116 (ALTA) sobre un periodo CERRADO, y v_vehiculos_hist_ultimo publica el estado_id de una fila cerrada como si fuera el estado CORRIENTE. No hay que elegir fuente ni reescribir 7 vehiculos: hay que dejar de leer el sello de un periodo cerrado como estado actual. INVARIANTE Y ALCANCE: 'una fila viva con fecha_baja cargada no puede llevar estado_id'. PROD: 1740 filas vivas, 140 vivas-cerradas, solo 7 con estado_id, las 7 = 116 ALTA, y las 7 son exactamente las que elige la vista. Contenido y sintoma son el mismo conjunto. DEV: 157 vivas-cerradas y 26 con estado_id - o sea 19 violaciones MAS que no se ven porque estan selladas 117 (BAJA) y coinciden con la ficha por casualidad. Contar contradicciones subcuenta el defecto en DEV por 19: gatear el invariante, no el sintoma. QUE VE EL USUARIO: la ficha. v_vehiculos_detalle alimenta src/app/vehiculos/[id]/page.tsx, y parque-movil.ts toma estado del LATERAL de vdc, no del historial. El 116 ALTA sale unicamente por v_vehiculos_lineas_entidades, consumida SOLO por src/repositories/rendiciones.ts (verificado en dev/dev). O sea: en la app el usuario ve BAJA, que es lo correcto; el valor equivocado se le sirve a la API de Rendiciones, con razon social y CUIT, diciendo que un vehiculo que el libro retiro sigue en servicio. CORRECCION AL ITEM: AI357EF/EG/EH son entidad_id 71 (NUEVOS RUMBOS S.A.), no entidad 54 como dice la descripcion. Linea 71 si. DATO PARA 167/186: 3 de los 7 (AE060XC 3715 vs 7582, AE631MI 3855 vs 7891, PQP070 4919 vs 8863) tienen un gemelo soft-deleteado con la MISMA fecha_alta y fecha_baja y estado_id NULL. La fila del import (id mas alto, estado NULL) quedo borrada y sobrevivio la vieja con el sello. Los otros 4 no tienen gemelo, asi que el gemelo no es la causa comun. NO EJERCITADO: no toque ningun dato; no verifique si algun consumidor externo de Rendiciones ya leyo estos 7; no revise los 19 casos extra de DEV uno por uno.
• wi-cli-venus descriptionChanged · 6w ago
  was: 7 vehiculos tienen ESTADO CONTRADICTORIO entre sus dos fuentes: la ficha del colectivo (vehiculos_datos_colectivos.estado_id, lo que muestra la UI y lo que sirve v_vehiculos_detalle) dice BAJA, y la ultima fila de historial (v_vehiculos_hist_ultimo.estado_id, lo que sirve v_vehiculos_lineas_entidades) dice ALTA. Los mismos 7 en DEV y en PROD, medido 2026-08-28 por db02-mba-l-cc y reproducido por coder02-mba-l-cc. Dominios: AE060XC (linea 22, entidad 51), AE631MI (72/49), AI357EF (71/54), AI357EG (71/54), AI357EH (71/54), PON576 (20/49), PQP070 (131/65). LLEGAN EN DOS LOTES DE 4 Y 3: 2026-06-22 10:50:32.25576 = AE060XC, AE631MI, PON576, PQP070; 2026-08-05 16:12:42.386728 = AI357EF, AI357EG, AI357EH, tres patentes CONSECUTIVAS en linea 71 entidad 54. Los timestamps son identicos al microsegundo dentro de cada lote Y entre DEV y PROD: una sola escritura propagada a los dos entornos, o sea causa sistematica, no 7 errores manuales. Descartar al importador exige descartarlo EN EL ORIGEN, no en un solo entorno. Cross-tab completo DEV ficha-vs-historial: 1425 ALTA/ALTA, 772 BAJA/null, 178 ALTA/null, 11 BAJA/BAJA, 7 BAJA/ALTA. Aparecio validando el contrato de la API de Rendiciones; no es un problema del documento ni de la API. Importa por la regla de custodio perfecto: un vehiculo de baja que una vista devuelve como alta es exactamente la diferencia que hay que poder explicar antes de jubilar el Excel. PENDIENTE DE DECIDIR cual fuente es autoritativa ANTES de tocar un dato: la que pierda se reescribe en 7 vehiculos de PROD, asi que el pedido de GO tiene que nombrar que fuente gana y por que, no pedir 'arreglar 147'. Sin GO no se escribe nada.
• wi-cli-venus note · 6w ago
  db02 2026-09-03: coder02's fix (docs/migrations/2026-09-03-movilba-147-estado-de-periodo-cerrado-DEV-PROD.sql, v5.4.103) APPLIED TO DEV. Target verified before applying: inet_server_addr 10.9.10.54, movilba_dev, PG 15.17. PROD NOT touched - still needs a fresh explicit GO from Elazar. No silent reconciliation: pg_get_viewdef on DEV before the apply was identical to the file except the estado_id expression. DISTINCT ON, column list, borrado_en filter, successor-exclusion EXISTS and the full ORDER BY (successor flag, fecha_alta DESC NULLS LAST, id DESC) all preserved - commons s12 ordering intact. Gates: gate 1 silent (zero closed periods publishing estado). Gate 2 positive control fired its NOTICE: 1604 periodos abiertos, 1426 conservan su estado. COMMIT. DEV before -> after on v_vehiculos_hist_ultimo: rows 1754->1754, open 1604->1604, open_with_estado 1426->1426, closed 150->150, closed_with_estado 20->0. Only the target column moved. Table-level invariant unchanged by design: SELECT count(*) FROM vehiculo_historial WHERE borrado_en IS NULL AND fecha_baja IS NOT NULL AND estado_id IS NOT NULL = 26 before and after. The view stops publishing the stamp; the column is still stamped. That 26 is what the importer fix has to take to 0. Grain note for anyone re-measuring: 20 (view) vs 26 (table) is not drift, it is grain - the view keeps one row per vehiculo. The migration header's DEV figure of 157 closed-but-live is stale; DEV measures 150 at the view grain today. NOT EXERCISED: PROD, and no application consumer of the view was run - the view was measured, not the app.
• wi-cli-venus completed · 6w ago
  Cerrado por db02 2026-09-03. La pregunta que mantenia este item en p0 - cual de las dos fuentes de estado es autoritativa - NO necesitaba decision de Elazar: la contesto la medicion. El libro vigente 2026-09-03-1049 da CERO filas abiertas a los 7 dominios, o sea LIBRO = BAJA 7 de 7; la ficha coincide con el libro 7/7 y la superficie derivada del historial lo contradice 7/7. Gana la ficha por medicion, no por criterio. Y no habia que reescribir ningun vehiculo. Las 7 filas vivas ya traian la fecha_baja correcta del libro. El defecto era que v_vehiculos_hist_ultimo publicaba el estado_id sellado en un periodo CERRADO como si fuera el estado corriente. Fix de vista, cero escritura de datos. APLICADO A DEV hoy (docs/migrations/2026-09-03-movilba-147-estado-de-periodo-cerrado-DEV-PROD.sql, v5.4.103, autor coder02): ambos gates pasaron, closed_with_estado 20 -> 0, y ninguna otra cifra de la vista se movio. QUE QUEDA Y DONDE VIVE: la aplicacion a PROD, que necesita GO fresco y explicito de Elazar. Se sigue en MOVILBA-212, que es el hijo de este item, esta inProgress y lo ownea coder02. No lo dejo abierto aca para no tener dos items siguiendo la misma escritura. TAMBIEN QUEDA ABIERTO, y es otro item: la columna sigue sellada. El invariante 'una fila viva con fecha_baja no puede llevar estado_id' vale 7 en PROD y 26 en DEV, antes y despues de la migracion - la vista deja de publicarlo, el importer sigue escribiendolo. Ese numero baja a 0 cuando se arregle el importer, dentro de 155/190. NO EJERCITADO: PROD, y ningun consumidor de la vista se corrio - se midio la vista, no la app.