El cutover de 441 reescribio los cuerpos de 9 vistas con un regexp que no distingue identificador de literal, y le rompio el lookup de catalogo a la fecha_alta del export de PROD
CORREGIDO 2026-09-17 15:10. La descripcion anterior de este item decia que la rama 'nacio muerta' y que 'nunca resolvio en ninguna base'. ES FALSO - ignorar esa version entera. La medicion del efecto se sostiene; el MECANISMO era otro y lo publique sin chequear el archivo que lo contradecia, que estaba a un grep. EL EFECTO (db02, PROD, 2026-09-17, se sostiene). `v_vehiculos_export.fecha_alta` resuelve el id del tramite ALTA con `grupo_nombre='public.v_vehiculo_historial'`, que no existe en `opciones`. El subquery da cero filas, `h.tramite_id = NULL` no matchea, el max() da NULL y el COALESCE cae SIEMPRE a `vdc.fecha_vigencia_desde`. Verificado sobre la tabla entera: 0 filas donde fecha_alta difiera del fallback, en todos los vehiculos no borrados. AE631MI: periodo vigente real abierto 2026-09-15 (fila 12981, tramite Alta), fecha_alta exportada 2026-04-21. LA CAUSA REAL. La terna estaba BIEN y estuvo VIVA del 2026-08-21 al 2026-09-16. `docs/migrations/2026-08-21-movilba-109-d-export-fecha-alta-por-vehiculo-PROD.sql` linea 14 la declara como (grupo 'vehiculo_historial', campo 'tramite', valor 'ALTA'), que es el grupo real (ALTA=317). La rompio el cutover de MOVILBA-441 el 2026-09-16. `2026-09-16-movilba-441-normalized-reader-cutover-{DEV,PROD}.sql` reescribe el cuerpo de 9 vistas con un regexp sobre el TEXTO de `pg_get_viewdef`: regexp_replace(source_sql, '(^|[^[:alnum:]_])((public)[.])?vehiculo_historial([^[:alnum:]_]|$)', E'\\1public.v_vehiculo_historial\\4', 'g') Un regexp sobre el texto de una vista NO distingue un identificador de un literal de string. En `'vehiculo_historial'::text` el caracter de antes y el de despues son los dos `'`, que satisfacen `[^[:alnum:]_]` de los dos lados: el literal matchea y queda `'public.v_vehiculo_historial'::text`. Reproducido mecanicamente contra ese patron exacto (python re, POSIX->py, 2026-09-17 15:08), no leido: BEFORE: o.grupo_nombre = 'vehiculo_historial'::text AFTER : o.grupo_nombre = 'public.v_vehiculo_historial'::text DEV se salvo por accidente: nunca recibio 109-D, asi que su export no tiene ese literal. Las dos bases corrieron el mismo rewrite. El censo de db02 (4 ternas limpias en DEV, 6 en PROD con 1 en cero) queda como esta y es correcto; contestaba otra pregunta. LA REPARACION es restaurar el literal a 'vehiculo_historial'. NO se crea un grupo 'public.v_vehiculo_historial' - esa era la unica conclusion que sobrevive de la version anterior, y ahora se sostiene por un motivo mas fuerte: el valor correcto esta escrito en el archivo aplicado. LO QUE NO LO ATAJO. La guarda del propio 441 es `IF rewritten_sql = source_sql THEN RAISE`: dispara solo si NO cambio nada. Prueba que hubo reescritura, jamas que se reescribieron solo relaciones. Es una guarda que no puede fallar ante este defecto - linea verde, no control. Regla de Elazar: un control que no se vio fallar no es un control. LA FORMA, que es lo que hay que censar y es distinta de la que pedi antes. No es 'ternas de catalogo que no resuelven' (esa ya se conto: 1 de 6). Es 'que MAS toco ese regexp'. Sobre las 9 vistas reescritas - v_audit_entidades_sin_vinculo, v_audit_lineas_sin_vinculo, v_audit_vehiculos_sin_vinculo, v_audit_vinculos_a_padre_borrado, v_db_users_footprint_detalle, v_monitor_historial_anomalias, v_vehiculo_cadena, v_vehiculos_detalle, v_vehiculos_export - en las DOS bases: cada aparicion de `public.v_vehiculo_historial` que este dentro de un literal de string en vez de en posicion de relacion, contada por vista, con el denominador (total de apariciones, split literal/relacion). Las familias v_audit_* y v_db_users_* son las candidatas: las vistas de auditoria suelen nombrar tablas como texto. Relacionado: MOVILBA-458 (los cuerpos difieren entre DEV y PROD), MOVILBA-453 (fecha_baja), MOVILBA-441 (el cutover, registrado como cerrado y verificado - no lo estaba), MOVILBA-242 (escritores de vdc.fecha_vigencia_hasta).
Activity
-
was: Sale de MOVILBA-453/458.
-
was: Medido por db02 en PROD, 2026-09-17, mientras ensayaba el archivo PROD-nativo de MOVILBA-453. EL DEFECTO. `v_vehiculos_export.fecha_alta` en PROD es un COALESCE cuya primera rama es un max(fecha_alta) de `v_vehiculo_historial` filtrado por el id del tramite ALTA, resuelto asi: SELECT o.id FROM opciones o WHERE o.grupo_nombre='public.v_vehiculo_historial' AND o.campo_nombre='tramite' AND o.valor_opcion='ALTA' AND o.borrado_en IS NULL Ese subquery devuelve CERO filas: en PROD no existe ningun `grupo_nombre='public.v_vehiculo_historial'`. El filtro interno queda `h.tramite_id = NULL`, que no matchea nada, el max() da NULL, y el COALESCE cae SIEMPRE a `vdc.fecha_vigencia_desde`. db02 lo verifico sobre la tabla entera: 0 filas donde fecha_alta difiera de vdc.fecha_vigencia_desde, en TODOS los vehiculos no borrados. NO ES 'la fila del catalogo se borro'. El grupo canonico es `vehiculo_historial` (ALTA=317, MODIF=318). `public.v_vehiculo_historial` es el nombre de la VISTA, no de un grupo, y ningun archivo de docs/migrations/ escribe jamas esa cadena como grupo_nombre (chequeado: los grupos que aparecen son validadoras, vehiculo_historial, vehiculo, motor, general, carroceria, ubicacion). O sea: quien escribio la vista puso el nombre del objeto donde va el nombre del grupo. La rama nunca estuvo viva, en ninguna base, en ningun momento. No es codigo que se murio - es codigo que nacio muerto. POR QUE IMPORTA MAS QUE UNA RAMA MUERTA. El fallback `vdc.fecha_vigencia_desde` lo escribe `materializar_snapshot_raices` una sola vez, al crear la raiz del vehiculo, y no se actualiza cuando el periodo se reabre - exactamente el mismo defecto que `vdc.fecha_vigencia_hasta`, que es lo que MOVILBA-453 vino a arreglar del lado de fecha_baja. Las dos puntas del export estan clavadas al momento de creacion del vehiculo. Se mantienen CONSISTENTES entre si porque estan congeladas en el MISMO periodo viejo, y esa consistencia es la que hizo que el fix de fecha_baja solo diera '0 contradicciones': se comparaba un valor viejo contra otro valor viejo. AE631MI lo prueba: el periodo vigente real abrio el 2026-09-15 (fila 12981, tramite Alta, importada hoy 12:54:48, ajena a cualquier cosa que hayamos corrido), y fecha_alta sigue resolviendo 2026-04-21. CONSECUENCIA DIRECTA SOBRE 453. Arreglar fecha_baja sola y dejar fecha_alta 'tal como esta instalada' deja a AE631MI con dos fechas equivocadas en Compensaciones en vez de dos fechas equivocadas y contradictorias. Se le saca la contradiccion al sintoma sin tocar el mecanismo. Si 453 se re-alcanza para arreglar las dos puntas juntas es decision de Elazar: cambia las fechas que ve Eugenia. LA FORMA, que es lo que hay que censar. Una vista resuelve un id de catalogo con una terna literal (grupo_nombre, campo_nombre, valor_opcion). Si cualquiera de los tres literales esta mal, el subquery da NULL, la comparacion `col = NULL` no matchea, y el resultado es un COALESCE que cae al fallback O una columna NULL - EN SILENCIO, sin error, sin fila que lo diga, y con un resultado que parece plausible. `pg_depend` no lo ve porque la dependencia es un string. Un grep tampoco, porque el string esta adentro del cuerpo de la vista. Censo pedido a db02 (solo lectura, DEV y PROD): toda vista o funcion que resuelva un id contra `opciones` por terna literal, ejecutando cada terna y contando las que devuelven cero filas. El denominador es cuantas ternas hay, no cuantas fallan. Relacionado: MOVILBA-458 (los cuerpos de la misma vista difieren entre DEV y PROD y nada lo compara), MOVILBA-453 (fecha_baja), MOVILBA-242 (escritores de vdc.fecha_vigencia_hasta).
-
El cutover de 441 reescribio los cuerpos de 9 vistas con un regexp que no distingue identificador de literal, y le rompio el lookup de catalogo a la fecha_alta del export de PROD
-
Mecanismo corregido en la descripcion. La version original decia 'nacio muerta / nunca resolvio en ninguna base' - es falsa y hay que ignorarla: la terna estaba bien en 109-D (2026-08-21) y la rompio el regexp de 441 el 2026-09-16. El efecto medido por db02 no cambia. Publique el mecanismo equivocado teniendo el archivo que lo contradecia a un grep; db02 y audit lo recibieron y db02 me lo devolvio adoptado - corregido en los dos por DM (coder03-mba-l-cc-mu5ub4hybour).
-
db02-mba-l-ca / db
-
AUDIT TRIAGE - DB batch #3. Repair the PROD catalog literal back to vehiculo_historial and census all 9 regexp-rewritten views for literal-versus-identifier damage. Use captured native definitions, no broad regex rewrite, and prove rollback/fresh reconnect before apply. Estimate: 2-4h.
-
Current-state verification and nine-view census complete; PROD catalog defect was already superseded by applied MOVILBA-445 native reconstruction. Recording evidence before closure.
-
Read-only census evidence: /data-lezama/movilba-web/evidence/2026-09-20-movilba-459-current-census-db02-mba-l-ca.md SHA256 2fa1e434479131c1628b4652f72341041b141b34e44cd1ca3159fbbe4efe9e7a. PROD v_vehiculos_export has canonical vehiculo_historial lookup, ALTA resolves once to 317, AE631MI=2026-09-15, and 1593/2413 rows differ from fallback. Nine-view census found only four non-operational metadata labels, identical DEV/PROD; zero remaining catalog-key damage.
-
Already repaired by applied MOVILBA-445 native reconstruction; verified current behavior and completed the required nine-view literal/relation census. No additional DB write is warranted.
-
INDEPENDENT AUDIT PASS 2026-09-20. Evidence SHA256 2fa1e434479131c1628b4652f72341041b141b34e44cd1ca3159fbbe4efe9e7a matches. Source commit 0dc7e5b9 confirms the PROD reconstruction uses canonical opciones tuple vehiculo_historial/tramite/ALTA. Current census proves 2413 export rows, 1593 fecha_alta values distinct from fallback, AE631MI=2026-09-15, and across all nine MOVILBA-441 views zero relation-position/catalog-key damage; four remaining occurrences are non-operational metadata literals. Closure as already repaired by MOVILBA-445 is correct; no DB write warranted.