El DROP de vehiculos_datos_colectivos.observaciones tiene GO para PROD pero DEV figura dropeada tres semanas antes y no hay archivo PROD

Sub-tickets

Activity

• coder03-mba-l-cc created · 1w ago
• db03-mba-l-cc note · 1w ago
  db03-mba-l-cc 2026-10-08, SELECT-only on PROD movilba and DEV movilba_dev. No DROP executed. Census: docs/reference/movilba-745-censo-vdc-observaciones.md, sha256 a53b458597b71f712621c7112ae1ee1edd40f4dcd52a66748c899d3006822f29, 75 lines, UNTRACKED. WHERE THE COLUMN IS. PROD movilba: vehiculos_datos_colectivos.observaciones EXISTS, text, nullable. DEV movilba_dev: ABSENT. Positive control on the probe: the same query against vdc.vehiculo_id in DEV returns integer. DEV lost it on 2026-09-18 via docs/migrations/2026-09-18-movilba-472-drop-vdc-observaciones-DEV.sql and there is no PROD file, so the order was INVERTED against PROD FIRST three weeks before the 12:55 GO. Same gap in the dependent view: public.v_vehiculos_export_vdc has 32 columns in PROD and 31 in DEV. drizzle/schema.ts is DEV-only evidence and cannot tell the two cases apart; pending-prod-changes.md:286,299,467,480 was the correct indication. INSTRUMENT DEFECT FOUND AND FIXED IN THIS PASS: a probe shaped coalesce((select count(...) ...),'ABSENT') can NEVER report ABSENT, because an aggregate returns a row with zero matches. It needs case when count(*)>0 inside. With the first version I read agents.v_vehiculo_lookup as present in PROD, where the whole agents schema does not exist. POPULATION IN PROD: 2424 rows, 1545 non-null and non-blank, 11 distinct texts. WHAT THE DROP DESTROYS: NOTHING. Residue is ZERO of 1545. Every populated text survives in at least one store the DROP does not touch. Per store: normalized history any period 1494, v_vehiculo_historial 1494, vehiculos_datos_colectivos_archive 1414, bkp.rutap0624prod_vdc_preimage 1, rutap.rutap_rows by dominio at tip snapshot 11 1494, any snapshot 1494. The 51 rows with no twin in normalized history are ALL in _archive. CORRECTION OF MY OWN FIRST DRAFT: it said 51 rows have no copy anywhere; that was an arithmetic error, I counted the other stores and then failed to subtract them. Positive control: with the text mutated the four counters fall to 0. The 51 are 7 distinct texts, dominated by Se modifico identidad, a pedido de la empresa 27, Se modifican datos, a pedido de la empresa 12, Se modificaron datos, a pedido de la empresa 8. They are not spelling variants of the vehicle's own history: relaxing the predicate to ignore punctuation, whitespace, accents and case, 1 of 51 survives and 50 still do not. And 50 of the 51 do not exist in the BOOK in any snapshot, so by ruling 4 of 2026-09-24 they are not SSOT data and removing them is routine sync, not loss. THE GO's PREMISE DOES NOT HOLD AS WRITTEN. The 3 vehicles it names, 3502 3953 4433, are NOT among the 51 and NOT among the 50 absent from the book: their texts exist in the same vehicle's normalized history AND in the book. I could NOT reproduce the figure 3 with any predicate - text absent from the whole book gives 50, distinct texts without a twin gives 7, vehicles with no history gives 0, distinct texts absent from the book gives 6. The 3 vehiculos con texto solo en vdc comes from a note of mine on MOVILBA-174 that did not write its predicate down. I am not calling it false, I am calling it NOT REPRODUCIBLE with the predicates I tried. REAL SCOPE OF THE DROP IN PROD, bigger than the GO describes. (1) v_vehiculos_export_vdc is the ONLY view naming the column, measured by pg_depend on the real refobjsubid, and NOTHING downstream reads that projection. PROD v_vehiculos_export and v_vehiculos_detalle already read observaciones from the current period, so PROD needs NO source re-pointing, unlike DEV. (2) CREATE OR REPLACE VIEW cannot remove a column, so it is a DROP VIEW and the transitive chain in PROD is TEN views, not the 7 of DEV: level 1 v_vehiculos_export_vdc, v_vehiculos_detalle, v_vehiculos_list; level 2 v_vehiculos_export, v_vehiculos_export_periodo_actual, v_vehiculos_api_public, v_vehiculos_list_alta, v_vehiculos_list_baja, v_vehiculos_vivos_estado; level 3 v_api_status. The four v_vehiculos_list* and v_vehiculos_vivos_estado are NOT in the DEV recipe. (3) All ten have relacl not null: 35 grants that a DROP VIEW discards and the migration must re-grant. This is absent from the DEV recipe because relacl was NULL there. (4) fn_archive_vehiculos_datos_colectivos() in PROD still names observaciones twice, in the target column list and as OLD.observaciones in the VALUES. A plpgsql body is not in pg_depend, so a bare DROP leaves it installed and failing at runtime on the first UPDATE/DELETE of vdc. That is the only part that breaks the application and the GO does not mention it; the converged body is in the DEV migration, lines 796-831. SEPARATE DEFECT, ITS OWN ITEM: the agents schema does not exist in PROD at all, while DEV has agents.v_vehiculo_lookup with 70 columns. DEV may diverge in ROWS only, never in objects. NOT EXERCISED: no live HTTP request. No real UPDATE/DELETE on vdc in PROD, so the runtime break in point 4 is derived from the function body and from how plpgsql resolves OLD, not observed. No ROLLBACK rehearsal of the DROP/CREATE chain in PROD - this item is the measurement, not the migration. The 289 origin-less stamp comments and the 17 per-dominio reviews of MOVILBA-174 were not measured. I did not split the 51 into vigentes versus bajas, which measures urgency and not correctness.
• coder03-mba-l-cc blocked · 1w ago
  Medido y NO ejecutado. db03 reporta: PROD TIENE la columna, DEV no - el orden se invirtio contra PROD FIRST el 2026-09-18, tres semanas antes del GO, y la vista dependiente arrastra el mismo hueco, 32 columnas en PROD contra 31 en DEV. El DROP no destruye nada: residuo 0 de 1545, cada texto sobrevive en _archive, en el historial normalizado, en el libro o en bkp, y 50 de los 51 sin gemelo de historial no existen en el libro en ningun snapshot, asi que quitarlos es sync rutinario bajo la regla 4. NO ES MOOT Y NO ES CORRIBLE COMO ESTA ESCRITO, por tres cosas que el GO no cubre. (1) El GO nombra vehiculos 3502/3953/4433 como el dato que se destruye; los tres estan a salvo, sus textos estan en el libro y en su propio historial, y db03 NO pudo reproducir la cifra 3 con ningun predicado - ese numero sale de una nota mia en MOVILBA-174 que nunca escribio su predicado, asi que la cifra del GO no tiene instrumento. (2) El alcance es mas grande que una columna: diez vistas en PROD contra las siete de la receta de DEV, con v_vehiculos_list*, v_vehiculos_list_alta/baja y v_vehiculos_vivos_estado faltando en esa receta, mas 35 grants que un DROP VIEW descarta y la migracion debe volver a otorgar - DEV nunca lo enfrento porque alli relacl era NULL. (3) fn_archive_vehiculos_datos_colectivos() todavia lee OLD.observaciones, asi que un DROP pelado la deja FALLANDO en runtime en la primera escritura a vdc. Esa tercera es la unica que rompe la aplicacion y el GO no la menciona. BLOQUEADO esperando que Elazar reconfirme el alcance con estos numeros. Conteo y alcance para el: 1545 valores poblados, 0 irrecuperables, 10 vistas reconstruidas, 35 grants restaurados, 1 trigger function reescrita. Evidencia: docs/reference/movilba-745-censo-vdc-observaciones.md sha256 a53b4585, 75 lineas, untracked.