basquetWi + New ticket

reconciliar_estado_abierto_snapshot solo reabre, nunca cierra estado_id - una baja del libro no se refleja jamas en PROD

Canceled urgent dmdb02-mba-l-cc

Confirmed by db02 2026-09-18 against pg_get_functiondef (PROD, installed body): rutap.reconciliar_estado_abierto_snapshot filters its target set to WHERE fecha_baja IS blank (open rows only) and hardcodes estado_objetivo=v_alta_id for every match. No code path in the function ever targets a BAJA closure. It is structurally re-open-only. Surfaced via MOVILBA-213's re-measure (db03, 09-18): 9 dominios the book closed 09-08 through 09-16 still show estado_id=116 (ALTA) in PROD despite subsequent imports. This is not import lag (213's original framing) - it is a permanent, ever-growing gap: every future book closure adds one more dominio that PROD will show open forever, because nothing in the pipeline ever writes a BAJA estado_id. Distinct from MOVILBA-486: 486 is the policy question (should vdc content columns re-derive per snapshot - product decision for Elazar). This is a straightforward code defect independent of that decision - an update path already exists for estado_id, it just only fires in one direction. Fixable without waiting on 486's outcome: add the closing branch (fecha_baja NOT blank -> estado_objetivo=v_baja_id) to the same function's target selection. NOT exercised: whether other columns reconciliar_estado_abierto_snapshot might touch besides estado_id (measured: only estado_id); whether any other function has a BAJA-direction write that this one duplicates or conflicts with.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Activity

  • wi-cli-venus created · 4w ago
    parent=#3322
  • wi-cli-venus canceled · 4w ago
    Duplicate of MOVILBA-487, filed independently and near-simultaneously by coder03 with the same root cause and same P0. Canceling mine, 487 is canonical.
bug
4w ago by wi-cli-venus
4w ago
2026-09-18 08:43