6 vehiculos activos sin fila vigente en RUTAP snapshot 4, sin explicacion: AG732SW AG771OC AG986KG AE631MI PQP070 AE060XC

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-20
• wi-cli-venus commented · 2026-08-20
  db-mba-l-cc classification 2026-08-20: all 6 are known to RUTAP but every row in their chain carries fecha_baja - no open tramite in snapshot 4, while prod shows all 6 active. Candidate-baja-not-yet-applied, same class as MOVILBA-44, NOT a book-vs-prod identity gap. AG732SW and AG771OC close 2025-12-12 with a BLANK expte_baja on the final row; AG986KG closes 2026-04-21 (EX-2026-18235670); AE631MI 2026-08-10 (EX-2026-35857037); PQP070 2026-08-07 (EX-2026-35649225); AE060XC 2026-08-07 (EX-2026-35801104). In 4 of 6 the trailing expediente points at a continuation tramite the export does not carry, so either Eugenia's snapshot is mid-chain or these are genuine bajas - NOT distinguishable from data alone. Decision: no SQL drafted, report to Elazar as a book question, same handling as MOVILBA-61.
• wi-cli-venus commented · 2026-08-20
  NARROWED to 2 vehicles, 2026-08-20. db-mba-l-cc's original 'all 6 active' used borrado_en only; audit-mba-l-ca checked estado_id and was right, db published the row-level table and retracted. FOUR are ALREADY correctly BAJA in prod with their own expte_baja and need NOTHING: AE060XC id3793 (2026-08-07, EX-2026-35801104), AE631MI id3953 (2026-08-10, EX-2026-35857037), AG986KG id6857 (2026-04-21, EX-2026-18235670), PQP070 id5181 (2026-08-07, EX-2026-35649225) - all estado 117 BAJA, borrado_en NULL, which is the correct shape. Only AG732SW id4510 and AG771OC id4511 are genuinely ALTA with no baja. For those two the BOOK is self-inconsistent: snapshot 4 carries an OPEN row alongside prior closed rows, same defect family as AH924PV. That is a question for Eugenia, not a prod write. Also recorded: expedientes are BATCH keys - EX-2026-18235670 spans 74 dominios / 147 rows - so a shared expediente never proves a same-chasis continuation.
• wi-cli-venus completed · 2026-08-20
  RESOLVED, 0 of 6 need a prod write. db02-mba-l-cc tiebreak with all five columns published; audit-mba-l-ca correct, db-mba-l-cc's 'all 6 active' retracted (read borrado_en, not estado). Four are already genuine BAJA in prod with their own expte_baja - AE060XC 3793, AE631MI 3953, AG986KG 6857, PQP070 5181 - and three of them have a named successor taking the same interno on the same linea on the exact close date with a DIFFERENT chasis (fleet replacement, not replate), all three successors live in prod as Alta: PQP070->AI325HY, AE060XC->AI444OZ, AE631MI->AI458AR. AG986KG has no successor: nobody holds interno 56 on linea 34 after 2026-04-21, the slot was retired. The remaining two, AG732SW 4510 and AG771OC 4511, are correctly ALTA in prod - each HAS an open row (fecha_baja NULL) in snapshot 4, so the ticket's second premise was also false. HOW THE LIST WAS BUILT WRONG: the selection used MAX(fecha_baja) as the terminal event, which cannot see the open row because max() over non-null dates silently skips the NULL; the blank expte_baja was the tell and got read as 'baja missing its expediente' instead of 'not a baja'. Same family as reference_a_gate_cannot_doubt_its_own_key.