131 vehiculos en BAJA quedaron sin ninguna fila activa de vehiculo_historial: falta la fila de cierre con su expediente_baja

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-20
• wi-cli-venus commented · 2026-08-20
  PRECONDITION added 2026-08-20 (coder02-mba-l-cc, agreed by coder-mba-l-cc): join Hoja2 BEFORE writing the 131 rows, not after. db02's coverage is 131/131 unanimous across vdc.expte_baja, historial expediente_baja and the RUTAP terminal row - but all three descend from the Base sheet, so the unanimity is weaker than it looks. Hoja2 (47 rows, DOMINIO | NUMERO EXPEDIENTE | Fecha, never ingested by anything - MOVILBA-70) is the only INDEPENDENT expediente source in the file. If it disagrees with the other three on any dominio it covers, that is a book-level conflict worth knowing before writing 131 rows. Also keep visible: 28 of the 131 carry more than one distinct expediente_baja across their historial rows and db02's historial figure used max() over them, so historial is corroboration and the RUTAP terminal row is the source.
• wi-cli-venus commented · 2026-08-20
  PRECONDITION CLEARED 2026-08-20 (db02-mba-l-cc): Hoja2 joined, ZERO overlap with the 131. None of Hoja2's 9 conflicting rows touches any of them, so the 131/131 three-source unanimity survives a check against the only source in the file that does not descend from Base. Expediente coverage for the restoration stands. The restoration itself still needs Elazar's per-file GO.
• wi-cli-venus commented · 2026-08-20
  CORRECTION 2026-08-20 (coder02-mba-l-cc, measured after ingesting Hoja2 as rutap_expedientes): Hoja2 is an ALTA document set - all 47 of its expedientes match on expte_ALTA and ZERO match on expte_baja. It therefore says nothing about the 131 bajas and cannot corroborate or contradict them. db02's 131/131 unanimity stands undisturbed; the earlier suggestion that Hoja2 might be an independent check on it was wrong - it is independent, but about the other event. Join trap for anyone using that table: Hoja2 writes EX-2025-30092573--GCABA-DGGSM (double hyphen, no spaces) while Base writes EX-2025-30092573- -GCABA-DGGSM (internal space run). Raw equality matches 22 of 47; normalizing spaces and collapsing the double hyphen matches 47 of 47. Two spellings of the same identifier inside one workbook.
• wi-cli-venus commented · 2026-08-20
  COUNT CORRECTED 2026-08-20 (coder02-mba-l-cc, self-caught): the '47 of 47 match' figure was JOIN PAIRS read as dominios - a dominio with several Base rows pairs more than once with the same Hoja2 expediente, and 47 pairs coincidentally equalled 47 rows. Counting DISTINCT dominios it is 38 match / 9 do not, which reproduces db02's split from the sqlite instead of the xlsx. Fourth instance in one night of a query that could not express what it was asked. UNAFFECTED, because measured differently: Hoja2 matches on expte_ALTA and never on expte_baja, confirmed from three directions (db02 zero-overlap, coder02, audit), so it remains an alta document set that says nothing about the 131 bajas.
• wi-cli-venus commented · 2026-08-20
  DENOMINATORS, pinned so the numbers stop colliding: 47 ROWS in Hoja2, 47 distinct dominios in the sheet, but 38 of those dominios match on expte_alta against their own Base chain and 9 do not (db02's split, reproducible from both the xlsx and the sqlite). The retracted '47 of 47' counted JOIN PAIRS. The spelling-trap figures - 22 raw vs 47 normalized - are ROW counts and are correct as written. Any figure quoted from Hoja2 must state whether it is rows, dominios or pairs.
• wi-cli-venus commented · 2026-08-20
  NUMBERS SUPERSEDED - do not quote '47 of 47' from the earlier note on this ticket, it was a join-pair count. Converged per-row figures, both lanes agreeing: 38 of 47 Hoja2 rows match expte_alta on their OWN plate's chain; 45 of 47 have an expediente that exists as an expte_alta somewhere in Base; 2 of 47 exist nowhere in Base on any plate (AH588XN 31492430, OIS896 29962951); and 0 of 47 match any expte_baja anywhere - the zero is what clears this ticket and it is unchanged. Dates, per-row form: of the 38 matched plates exactly 1 agrees with Base and 37 differ. Delta measured as Hoja2.Fecha minus Base.fecha_alta runs -103 to +12 days: Hoja2 is a few days LATER in most, and up to 103 days EARLIER in 8 - the early outlier is the one that sits worst with the document-date hypothesis, since a document dated 103 days before the tramite it documents is odd while one dated days after is not.
• wi-cli-venus commented · 2026-08-20
  DATE SPREAD CORRECTED AGAIN, verified independently by coder-mba-l-cc against the xlsx + sqlite: the -103 day outlier is ITSELF a fan-out artifact and does not exist. All-pairs over 47 join rows gives -103..+12; per Hoja2 row against the nearest Base row carrying that expediente on that plate, n=38, the range is -7..+12 - 1 same date, 35 Hoja2 later (max +12), 2 Hoja2 earlier (max -7). Reproduced exactly by two lanes. This INVERTS the reading: 'two sheets of one file disagree by up to 103 days' is a book contradiction; 'Hoja2 is a few days after Base on nearly every plate, never more than 12' is two consistent-but-different date semantics, which is what the document-date-vs-effective-date hypothesis predicts. The one case that argued against that hypothesis was the artifact. Fifth instance tonight of a query measuring something other than its name, and the FIRST found inside a correction to a previous instance: the all-pairs join was already known wrong for counting, and nobody re-checked the aggregate computed over the same join. Fixing a count and leaving a max() over the same fan-out is its own failure mode. Which framing to quote: all-pairs answers 'does Hoja2 agree with EVERY Base row carrying this expediente' and is guaranteed to disagree whenever an expediente spans two periods - a property of the chain, not of the sheets. Per-row-nearest answers 'is Hoja2 consistent with Base at all' and is the honest one for a question to Eugenia.
• wi-cli-venus commented · 2026-08-20
  PREMISE CORRECTED 2026-08-20 and the write is ON HOLD - not cancelled - pending a new Elazar GO on true facts. NOTHING WAS LOST: the soft-deleted historial row of each of the 131 already carries expediente_baja (131/131, agreeing with both vdc and the RUTAP terminal row) plus non-null entidad_id and linea_id. Independently corroborated: v_vehiculos_hist_ultimo falls back to the soft-deleted row and the export shows linea/entidad for all 137 bajas with zero NULLs, which is only possible if that data is still there. So the only defect is v_vehiculos_linea_actual having no fallback - MOVILBA-65, a view change with zero writes. ORDER INVERTED: 65 runs first; writing 131 rows first would make its fallback look unnecessary BY CONSTRUCTION rather than on the merits, destroying the evidence needed to judge it. WHAT 69 REALLY IS: prod holds one state in two shapes - 6 bajas keeping an ACTIVE historial row stamped with expediente_baja (AE060XC, AE631MI, PQP070, AI357EF/EG/EH - all 6 now stamped, three by MOVILBA-44 and three by the sync's pass B tonight) and 131 holding the same data on a soft-deleted row. That is a NORMALISATION decision, not a recovery: 131 writes plus 131 archive-trigger side effects against data that is not lost. DESIGN CONSTRAINTS if it ever runs: MOVILBA-44's shipped pattern does NOT insert a closing row, it keeps the vigente row active and stamps expediente_baja. But do NOT copy its estado_id blindly - model row 5052 carries estado_id 116 ALTA on a vehicle whose vdc says BAJA, and estado_id is NULL on all 131 source rows: historial never tracked baja state at all (reference_estado_no_esta_en_vehiculo_historial). Decide deliberately what estado_id means on that row.
• wi-cli-venus commented · 2026-08-20
  GO de Elazar 2026-08-20 sobre la premisa CORREGIDA (normalizacion de 131 filas, no recuperacion - nada se perdio).
• wi-cli-venus commented · 2026-08-20
  MEDIDO por db02 (sin escribir). Operacion real = 131 UPDATE que limpian borrado_en en UNA fila cola-de-cadena por vehiculo. NO es stamp, es UNDELETE. Evidencia 1:1 en 3 ejes, 131/131 exactos, cero excepciones (historial.expediente_baja = vdc.expte_baja = fila terminal RUTAP). Triggers: vehiculo_historial tiene UN solo trigger, BEFORE DELETE - un UPDATE no dispara nada, delta de archive = 0 (mi premisa de '131 efectos de archivo' era falsa). TRAMPA: 28 de los 131 tienen mas de una fila y TODAS llevan expediente_baja, asi que expediente_baja NO identifica la ultima. Las filas forman CADENA: expediente_baja de una es expediente de la siguiente. v_vehiculos_hist_ultimo (fecha_expediente DESC, creado_en DESC) elige mal en 3 casos por empate de fecha. REGLA OBLIGATORIA para 69: 'la fila cuyo expediente_baja no es el expediente de ninguna hermana' - devuelve 131/131 y matchea vdc 131/131. estado_id EXISTE en historial: 116/ALTA en 1604, NULL en 2441, 117/BAJA en CERO filas - nunca. Registra el estado que ABRIO el expediente, no el actual. PREGUNTA ABIERTA PARA ELAZAR: estado_id queda NULL (como las 131 hoy) o pasa a 116 (como las 6 bajas de referencia).
• wi-cli-venus commented · 2026-08-20
  estado_id RESUELTO por medicion (db02): queda NULL. estado_id esta 100% predicho por creado_por - system_import 1599/1599 con 116, import-rutap-2026-08-14-prod 2274/2274 con NULL, ningun importador mezcla. Es PROCEDENCIA, no estado. Forma normal de periodo cerrado = NULL (2291 filas) contra 116 (8 filas, de las cuales 6 son las bajas de referencia de MOVILBA-44) - la cohorte de 6 era la anomalia, no el patron. Ademas las 131 salieron todas del importador cuya salida completa es NULL: estamparles 116 las volveria las unicas filas con valor que ese importador produjo. Y escribir estado_id convierte el undelete en undelete-mas-edicion, mas ancho que la operacion aprobada. Pendiente contra-argumento de audit.
• wi-cli-venus commented · 2026-08-20
  CONSENSO 3/3 (db02 midio, audit ratifico, db sin objecion): estado_id queda NULL. Sentencia para el GO de Elazar: '131 UPDATE sobre vehiculo_historial que limpian borrado_en en UNA fila cola-de-cadena por vehiculo, elegida por la regla de cadena (la fila cuyo expediente_baja no es el expediente de ninguna hermana); sin INSERT; estado_id NO se toca, queda NULL; ningun trigger dispara; verificado 1:1 contra RUTAP en 3 ejes a 131/131.'
• wi-cli-venus completed · 2026-08-20
  APLICADO Y COMMITEADO EN PROD 2026-08-20 05:08 ART por db02-mba-l-cc, con GO de Elazar sobre la sentencia corregida (UNDELETE, no stamp). Ensayo limpio, despues apply=true, ambas pasadas identicas, seis gates. 131 UPDATE, cero INSERT (total 4045 sin cambio), estado_id intacto en NULL. Censo post-commit como svc_nextjs: bajas sin fila viva 131 -> 0, con fila viva 6 -> 137, filas vivas 1605 -> 1736, export 1736 sin moverse, v_vehiculos_detalle 1736 filas / 1736 vehiculos sin fan-out. Prod tiene UNA sola forma para un estado; la division en dos formas que freno este ticket dos veces desaparecio. El .sql quedo en el repo.