PROD contra el libro vigente: 15 bajas que la ficha muestra en ALTA, 1 alta que muestra en BAJA, y 16 vigentes del libro sin ficha en PROD
Medido 2026-09-03 por db02-mba-l-cc (SELECT) comparando la FICHA de PROD (vehiculos_datos_colectivos.estado_id, filas vivas) contra el LIBRO VIGENTE /data-lezama/rutap-ssot/2026-09-03-1049-parque-rutap.xlsx (md5 b9880577fb9d886bfca4aaadba124ea5), hoja Base, encabezado fila 2, descartando el relleno sin dominio. Estado del libro derivado POR DOMINIO: ALTA si tiene alguna fila con Fecha_Baja vacia, BAJA si todas cerradas. DENOMINADORES: 2404 dominios en el libro, 2388 fichas vivas en PROD, 2372 coinciden. CONTROL POSITIVO: la comparacion tuvo 2388 entradas; cero dominios de PROD estan ausentes del libro (o sea MovilBA no inventa vehiculos). A) 15 vehiculos que el LIBRO dio de BAJA y la ficha de PROD sigue mostrando en ALTA: AD482RQ, AD532MG, AE260QQ, AE548EW, AE548EX, AE573LB, AE590KF, AE736PI, AE992PE, AF928ID, AG497GZ, PNX655, POD392, POD394, PQW567. B) 1 vehiculo que el LIBRO tiene ABIERTO y la ficha de PROD da de BAJA: AG986KG. C) 16 dominios del libro SIN NINGUNA FICHA VIVA EN PROD, y los 16 son VIGENTES en el libro (fila abierta): AA195PH, AA195PJ, AA247VF, AB126BE, AB126BG, AB126CZ, AI282LZ, AI334UO, AI429RW, AI429SH, AI482RD, AI501JL, AI501JV, AI513QP, PMI009, PMI013. No es un estado equivocado: son 16 colectivos EN SERVICIO que MovilBA no muestra. Total de la brecha de fidelidad de PROD contra el libro, en estado y presencia: 32 vehiculos. ESTO ES LA FICHA, o sea la superficie que el usuario VE (v_vehiculos_detalle -> src/app/vehiculos/[id]/page.tsx, y el LATERAL de vdc en parque-movil.ts). No es el caso de MOVILBA-147, que vive solo en la superficie derivada del historial. PISTA DE CAUSA para 3 de los 15 (AE590KF, POD392, POD394): en DEV estan correctamente en BAJA, escritos por creado_por='import-rutap-snapshot-7'. Ese loader NO EXISTE en PROD (cero filas de vehiculo_historial con creado_por like 'import-rutap-snapshot%'). O sea DEV recibio un snapshot que PROD no recibio. Los otros 12 no estan explicados y no se deben asumir de la misma causa sin medirlos. NO EJERCITADO: no compare campos de negocio, solo ESTADO y PRESENCIA. No mire si los 16 ausentes tienen fila de vehiculos sin ficha o no existen del todo. No verifique DEV contra el libro. Cero escrituras.
Sub-tickets — 1/1 done
Activity
-
MEDIDO POR coder02 2026-09-03: los 16 dominios sin ficha en PROD NO son un defecto propio - son el retraso de libros de MOVILBA-155 con numero. Presencia de esos 16 en cada libro: 08-31 tiene 6, 09-01 tiene 10, 09-03 tiene los 16. Crecen monotonamente libro a libro, o sea son altas nuevas que Eugenia va cargando y PROD nunca importo. Mismo fenomeno que MOVILBA-192 conto como '10 ausentes' cuando el libro vigente era el del 09-01. NO investigar los 16 uno por uno: el fix es importar el libro 2026-09-03-1049. Lo que SI queda como pregunta propia tras el import son los 15 que la ficha muestra ALTA y el libro retiro, y AG986KG al reves - esos no se explican por retraso porque el dominio ya esta en PROD.
-
parent=MOVILBA-155
-
1
-
RESUELTO POR MEDICION, sin residuo de investigacion (db02, 2026-09-03, SELECT en PROD + los 7 libros archivados). LOS 32 SON UNA SOLA CAUSA: PROD esta atrasado de libros. Ninguno de los tres grupos es un defecto propio. coder02 ya habia mostrado eso para el grupo C (los 16 ausentes crecen monotonamente 6 -> 10 -> 16 libro a libro). Aplique el MISMO metodo a los grupos A y B, que era lo que quedaba abierto. GRUPO A - los 15 que la ficha muestra ALTA y el libro retiro. Estado del dominio en cada libro archivado: 08-24: los 15 ALTA 08-27: 3 en BAJA (AE590KF, POD392, POD394) 08-31: 8 en BAJA 09-01: 12 en BAJA 09-03: los 15 en BAJA PROD muestra ALTA en los 15. O sea el libro los fue cerrando en las ultimas cuatro versiones y PROD nunca importo ninguna. No son 15 casos: es un import que falta. Y NO ES UNA CONTRADICCION FICHA-VS-HISTORIAL. En 14 de los 15 la fila de historial vigente tambien dice 116 ALTA con fecha_baja NULL, todas creado_por='system_import': las dos superficies de MovilBA estan de acuerdo entre si y las dos contradicen al libro. Esto NO es MOVILBA-147. GRUPO B - AG986KG, el caso inverso. El libro del 08-24 lo tenia en BAJA y desde el 08-26 lo tiene ABIERTO. PROD guarda BAJA, con fila de historial fecha_baja 2026-04-21, estado_id NULL, creado_por='import-movilba-19'. PROD es FIEL al libro del 08-24 y no aprendio la reapertura. Mismo atraso, direccion contraria. CONSECUENCIA PARA EL ITEM: 213 deja de ser una investigacion y pasa a ser el TEST DE ACEPTACION de MOVILBA-155. Despues de importar 2026-09-03-1049 los 32 tienen que dar cero. Si alguno sobrevive al import, ESE si es un defecto propio y recien ahi se investiga. RESTRICCION DE ORDEN, y es la parte accionable: AF928ID esta en los 15 Y en las 170 filas de MOVILBA-216 (su fila vigente es la del loader snapshot5, estado_id NULL y fecha_baja NULL). Completar 216 ANTES del import le escribiria ALTA a un vehiculo que el libro retiro. 155 primero, 216 despues. Vale como regla general, no solo para AF928ID: el conjunto de 170 se deriva del libro y el libro esta por cambiar. CONTROL POSITIVO: la matriz se corrio sobre los 7 libros y los 16 dominios; ninguna celda quedo sin resolver, y AG986KG se mueve en direccion contraria a los otros 15, asi que el detector no esta devolviendo un valor constante. NO EJERCITADO: no compare campos de negocio de estos 16, solo estado y presencia. Cero escrituras.
-
db03 re-measure 2026-09-18 04:29 (delegated by db02, SELECT-only), PROD + current book /data-lezama/movilba/libro/2026-09-17-0942-parque-rutap.xlsx (2413 dominios, matches MOVILBA-192 close). Groups B and C: ZERO (AG986KG resolved, all 16 vigentes-missing now present). Group A: 9 of 15 original resolved, but 9 NEW dominios now fail the same check (book BAJA, PROD ALTA): AA480BB, AC213TA, AC363OK, AF894KI, AF894KJ, AF894KR, AG202SX, AG202SZ, AG232XB. None of these 9 overlap the original 15. Book rows for all 9: fully closed history, most recent Fecha_Baja 2026-09-08 through 2026-09-16, all modif-chain, all with Expte_Baja present. PROD still shows estado_id=116 (ALTA) for all 9 live vdc rows. No estado_id outside 116/117, no dominio-count mismatch (2413=2413 both sides), no orphan on either side. Pattern matches the original defect (PROD import lag), not fixed structurally by MOVILBA-155/435 - just cleared for the batch as of 09-03. NOT investigated: root cause per-dominio (creado_por/origen_ingreso not pulled), no DEV comparison. Cero escrituras.
-
db03-mba-l-cc
-
db03 2026-09-18 ~12:35 ART. RE-MEASURED today, SELECT only, DEV + PROD (PROD read as svc_nextjs, not superuser). Compared: book state per dominio (ALTA if any row of that dominio in rutap.v_rutap_latest_norm has fecha_baja NULL, else BAJA) vs the FICHA surface = public.v_vehiculos_detalle.estado_actual (upper-cased; the label is 'Alta'/'Baja', a raw string compare against 'ALTA' returned a false zero on my first pass and I caught it because the coincide count came out 0). PROD (book snapshot id 2, 2413 dominios; 2413 live vehiculos = 2413 ficha rows, 0 duplicated): - book split ALTA 1600 / BAJA 813; ficha Alta 1599 / Baja 814. - coincide 2412 of 2413. - A (book BAJA, ficha ALTA): 0. Original 15 = 0, and the 9 second-wave dominios from db03's 04:29 note (AA480BB, AC213TA, AC363OK, AF894KI, AF894KJ, AF894KR, AG202SX, AG202SZ, AG232XB) = 0. Fact, not a structural claim: they were 9 at 04:29 today and are 0 now, and PROD data writes landed in between (486 apply, per db02); I did not map each dominio to a write or read 486's body, so I state no mechanism. - B (book ALTA, ficha BAJA): 1 = AC098EJ. NOT a defect: book has an OPEN Modif (2025-07-17) AND a later-closed Alta (2025-07-08..2025-12-29); the current period is the most recent BUSINESS event, decided by MOVILBA-344 (header L24-58 names 3530 AC098EJ, Elazar GO knowing the flip), already logged for Eugenia, audit-confirmed 14:11 today on MOVILBA-177. db02 wrote over it in PROD this morning and reverted (archive_id 32746). Do not touch. - C (book dominio with no ficha): 0. D (ficha with no book dominio): 0. The original 16 vigentes-sin-ficha and AG986KG are all resolved. - POSITIVE CONTROL: flipping 3 book states in a temp copy makes the same detector report 4 mismatches = 3 flipped + the 1 real. The detector discriminates. DEV (book snapshot 16, 2413 dominios; 2430 live vehiculos): coincide 2411; A 0; C 0; B 2 = AC098EJ (same decision, same rows) + AH007QZ; D 17 = DHU474, EG111AA, FB345EP, FB444EP, FB555EP, FGG123, JM111NA, LB221PE, LB333EP, LP456PE, LP555EP, MC444FO, PB111AA, PB111PB, PB311AA, PB455EP, PR149II (DEV-only test dominios, absent from the book, expected). AH007QZ: book has an open Alta 2026-08-14; DEV ficha says Baja because a user edit set estado_id=117 on vdc 5610 today 10:16:40 (audit_log id 980, user 20349069890, action UPDATE, `estadoId` in changes; the archive row before it is 116). That is user-created DEV data - protected, not import drift. PROD has AH007QZ = Alta, equal to the book. Result: the acceptance test of MOVILBA-155 that this item became (all 32 = 0) passes on PROD except the one decided book contradiction. Closing. NOT EXERCISED: only ESTADO and PRESENCIA were compared, no business field; the ficha surface only (v_vehiculos_detalle), not the export or the API views; DEV/PROD compared against each env's own current book snapshot, not against the xlsx on disk (book snapshot in PROD is id 2, one row in rutap.snapshots).
-
db03 2026-09-18: closed on today's re-measurement, see the last event on this item.