reconciliar_snapshot particiona por (vehiculo_id, dominio), la misma forma que fue defecto en v_vehiculo_historial_actual - latente hoy porque esta gateado a una fila por vehiculo
Flag de db03-mba-l-cc mientras media MOVILBA-487 (2026-09-23). La ventana de rutap.reconciliar_snapshot sigue siendo PARTITION BY vehiculo_id, dominio. Es exactamente la clave demasiado ancha que en MOVILBA-552 le daba a cada patente de un mismo vehiculo_id su propio rank 1 por construccion. Hoy NO es defecto porque la funcion mira solo filas import y esta gateada a una fila por vehiculo, o sea que la particion por dominio no puede producir un segundo ganador. Eso es una propiedad de los datos de hoy, no del codigo: el dia que un mismo vehiculo_id tenga dos dominios vivos en el import - que es una forma legitima del libro, no una anomalia - la particion devuelve dos filas y el reconciliador escribe dos estados objetivo para un solo vehiculo. Medir primero si el gateo a una fila por vehiculo es estructural o incidental; si es incidental, alinear la particion a vehiculo_id como se hizo en 552.
Activity
-
coder03-mba-l-cc
-
db04-mba-l-ca
-
db03-mba-l-cc / db
-
db03 2026-10-08: measured the thing this ticket asked to measure first ("medir primero si el gateo a una fila por vehiculo es estructural o incidental"). Structural. Closing - no realignment needed, 552's fix does not apply here. rutap.reconciliar_snapshot's rutap_reconcile_source CTE (lines ~59-82 of the current function body) does partition the ranking window BY (vehiculo_id, dominio), same shape flagged in 552. But immediately after building it, an explicit cardinality gate runs (lines 92-96): SELECT count(*), count(DISTINCT vehiculo_id) INTO v_n, v_vehiculos FROM rutap_reconcile_source; IF v_n <> v_vehiculos THEN RAISE EXCEPTION 'reconciliar: la fuente no es una fila por vehiculo (% filas, % vehiculos) - el desempate no alcanzo', v_n, v_vehiculos; END IF; This is unconditional, runs on every call, and is a hard RAISE EXCEPTION, not a log or a silent branch. If a vehiculo_id ever carries two live dominios in one snapshot (v_n for that vehiculo_id = 2, distinct vehiculo_id count = 1 for the group), v_n <> v_vehiculos fires and the WHOLE function aborts - the entire reconciliation transaction rolls back, not just that vehiculo_id. This is the opposite outcome from the one the ticket worried about ("el reconciliador escribe dos estados objetivo para un solo vehiculo"): it cannot write two target states for one vehicle, because any such case prevents ALL writes for ALL vehicles in that run. Confirmed this gate is not something that landed after the ticket was filed (2026-09-23): grepped docs/migrations/ for its exact RAISE text ("el desempate no alcanzo") and it already appears in 2026-09-18-movilba-486-reconciliar-snapshot-DEV-Y-PROD.sql, five days before this ticket was created - so the premise ("hoy NO es defecto porque... es gateado a una fila por vehiculo" being merely incidental data-shape luck) is wrong: it was never incidental, it's a written, tested gate. Residual, separate from this ticket's ask: a real two-live-dominios-per-vehiculo_id book row would halt reconciliation entirely (availability, not correctness) until resolved - same class as every other RAISE EXCEPTION gate in this function (SSOT Tipo exact match, FK presence, etc). Not a new finding; it is this function's established fail-closed posture throughout. Not filing a new ticket for it - it is the intended behavior of every gate in reconciliar_snapshot, and 552's "align partition to vehiculo_id" would trade a loud abort for a silent wrong write, which is a worse outcome here, not a fix.
-
db03: gateo confirmado estructural (gate explicito, predate el ticket). No se realinea la particion - 552 cambiaria un abort ruidoso por una escritura silenciosa peor. Ver nota.