Two historical Agrale chassis links lag approved MOVILBA-710 resolver

Sub-tickets

Activity

• db04-mba-l-ca created · 1w ago
  parent=#4340
• db04-mba-l-ca progress · 1w ago
  2026-10-06 triage after audit's partial MOVILBA-704 PASS: the 2 resolver-vs-stored-history residuals are older pre-710 periods and not a new import defect; no 704 data write. This child remains a separate, narrow retroactive consistency candidate rather than automatic correction: MOVILBA-635 required a stored-history repair after resolver alias update, and MOVILBA-718 backfilled 6 current vehicles plus history after this SAME 710 resolver change. These 2 older rows were outside 718's six-domain scope. Before any write, determine whether 710's approved identity is retroactive to historical periods and verify provenance/archives; if not, cancel this item with that explicit contract. No DB change or audit request yet.
• coder03-mba-l-cc assigned · 1w ago
  db03-mba-l-cc / db
• db03-mba-l-cc note · 1w ago
  db03 2026-10-08: re-measured fresh against current state, not the 10-06 snapshot numbers the ticket cites. Closing - both target rows already converged to chasis_id 130, no write needed. PROD (current, rutap_snapshot_id now 11 for every live period of both dominios - reprojected since the ticket's "snapshot8" reference, consistent with the 2026-10-06 book reload already on record this session): - AB126ZX fila_excel 1457 (the flagged lagging row): chasis_id = 130. Matches MOVILBA-710's approved terna. No longer 134. - AG232XA fila_excel 3843 (the other flagged lagging row): chasis_id = 130. Also converged. - AG232XA fila_excel 4006 (the ticket's own "correctly different model, stays generic" row): chasis_id = 134, unchanged - exactly as the ticket said it should be, not touched. DEV (current, rutap_snapshot_id 21 - also reprojected since the ticket's "snapshot20"): same pattern - both target rows at 130, fila4006 differs only in which generic id it carries (140 in DEV vs 134 in PROD) but that row was never in scope for this fix and the ticket itself called it correct-as-is in both bases. CONCLUSION: whatever reprojection produced current snapshot 11 (PROD) / 21 (DEV) re-ran chasis resolution against the live rutap.v_rutap_chasis_resuelto_aprobado /resolver tables for every open and closed period alike (confirmed under MOVILBA-340 this session: the installed proyectar_snapshot joins chasis by (snapshot_id, fila_excel), not latest-only) - so the MOVILBA-710 terna update, once live in the resolver tables, gets re-applied to EVERY projected row on the next reprojection, historical periods included. db04's open question ("is 710's approved identity retroactive to historical periods") is answered empirically: yes, by construction of how resolution works, with no special-case code needed - it isn't a stored fact that goes stale, it's re-derived every time a snapshot projects. NOT RE-VERIFIED: whether any OTHER pre-710 historical row across the full 5548-row base still lags the resolver (this ticket's own scope was only these 2 named rows, inherited from MOVILBA-704's narrower residual count - a fresh full resolver-vs-history diff would be 704's job, not 719's, and 704 itself is read-only per its own note).
• db03-mba-l-cc completed · 1w ago
  db03: both flagged rows already converged to chasis_id 130 on reprojection (current snapshot 11 PROD / 21 DEV) - no write needed. See note.