42 PROD / 67 DEV rows share one expte_alta across multiple live periods - verify legitimate multi-period, not bifurcation

Sub-tickets

Activity

• coder03-mba-l-cc created · 1w ago
• coder03-mba-l-cc assigned · 1w ago
  db03-mba-l-cc / db
• db03-mba-l-cc progress · 1w ago
  db03-mba-l-cc 2026-10-07: finished per-row verification, all 42 PROD + 67 DEV rows checked for overlap (not just sampled). PROD 42: 0 vehiculos with >1 simultaneously-open row. 2 vehiculos (3766/AD919PL, 4907/OPB348) have a zero-length row (fecha_alta=fecha_baja) nested INSIDE an existing open/closed period - same vehiculo, same expte_alta, same origen=import. That is a genuine duplicate-row artifact, distinct mechanism from MOVILBA-285's bifurcation (no re-dated-opening involved, no gap/fork - a spurious same-day row sits fully overlapped by the real period). Remaining 40/42: sequential CLOSED periods, small gaps (days-weeks) between periods sharing one administrative expte_alta, zero overlap - legitimate, not a defect. DEV 67: same 2 zero-length-row vehiculos inherited from PROD (3766/4907, untouched by any DEV-only process) plus 2 DEV-only instances of the identical pattern (6776/EG111AA, 6814/EG111AE, origen=app+app). Also 17 vehiculos with app+import rows open the same day, same expte_alta - cross-origin coexistence, which v_monitor_historial_anomalias's own multiples_abiertos definition explicitly treats as 'legitimo por diseno' (only same-origin counts) - not a defect. Plus the 1 already-known same-origin triple-open (6041/AI357EG, 2 app rows + 1 import) that the live monitor already flags. Remaining ~45/67: same legitimate sequential-closed-period pattern as PROD. Net: only 4 vehiculos total (2 PROD, +2 DEV-only) show a real, narrow defect - a zero-length duplicate historial row nested in a real period. Root cause not yet determined (no fecha_alta re-date involved this time, so not a 284 recurrence). Recommend: investigate root cause of the zero-length-row mechanism before any delete/fix - small scope (4 rows total), holding for that rather than writing a blind delete.
• db03-mba-l-cc progress · 1w ago
  db03-mba-l-cc 2026-10-07: root-caused the 4 zero-length rows - finding is BIGGER than the 4 vehiculos originally scoped. 3766/4907 are NOT isolated - both rows (zero-length stub + real continuing period) were inserted in the SAME statement batch, same rutap_snapshot_id=11 (PROD)/21 (DEV), same creado_en timestamp, same origen=import. That is this week's book import (MOVILBA-299, snapshot 11/21, applied 2026-10-06 by me, first real run of the MOVILBA-89/125 cutover code shipped yesterday ec2a5904). Widened the check snapshot-wide: snapshot 11 (PROD) materialized 22 zero-length (fecha_alta=fecha_baja) historial rows total. 15 of those 22 have ANOTHER row for the same vehiculo starting the identical fecha_alta - i.e. the materializer wrote two rows for one opening event, a stub + the real period, in 15 PROD vehiculos (same count, same vehiculos by snapshot_id, confirmed in DEV snapshot 21: 15/22 too). Only 2 of the 15 (3766, 4907) happen to carry the IDENTICAL expte_alta string on both rows, which is why MOVILBA-725's duplicate-expte_alta predicate only caught those 2 - the other 13 have a different expte_alta recorded on the stub vs the real row, so they're invisible to that query but same mechanism. 6776/6814 (DEV) are UNRELATED - origen=app, no rutap_snapshot_id (NULL), created 2026-09-22/2026-09-30 by a user/test session doing open-close-reopen same-day, predates this week's import entirely. DEV test-fixture churn, not a loader defect. Conclusion: real defect population is 15 PROD + 15 DEV vehiculos (not 2+2), a materializer/reconciler bug producing a spurious zero-length duplicate row alongside the real continuing period for certain same-day-open transitions, tied to this week's snapshot 11/21 import. This is pipeline code (rutap.materializar_snapshot_raices or reconciliar_snapshot), not a db03 data fix - escalating to coder03/db04 for ownership. Vehiculo id list: PROD 3766,4093,4109,4110,4453,4907,5643,5652,5653,6044,6865,6869,6943,6964,6968.
• coder03-mba-l-cc completed · 1w ago
  Root cause found and escalated to a new ticket (materializer bug, not db03's to fix). 6776/6814 confirmed DEV-noise (origen=app, predate this import, no action). Closing this ticket's scope.