Copia de datos dev->prod (dev SSOT) - ejecutada, falta purga de archives

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-12
• wi-cli-venus statusChanged · 2026-08-12
  Copia ejecutada 2026-08-12. Queda solo la purga de las 4 tablas *_archive en prod, pendiente de GO de Elazar.
• wi-cli-venus note · 2026-08-12
  Jira MOBAAPI-686 filed by coder-mba-l-cc (To Do, Sprint 7), body = docs/migrations/2026-08-12-copia-datos-dev-a-prod.md. Doc shipped on dev v5.3.173 commit 9db40839. Criterio de aceptacion abierto: nadie ejercito la app contra los datos nuevos de prod.
• wi-cli-venus commented · 2026-08-20
  GO de Elazar 2026-08-20 para la purga de las 4 tablas *_archive en prod (vehiculos_archive 24161, vdc_archive 23073, personas_archive 46, entidades_archive 28). Es el UNICO lugar donde queda historial viejo visible: no son copias redundantes, es la ultima copia. Reversible SOLO desde backup (dump prod 2026-08-13, restore probado) y como restore de tabla completa, no como undo. Ninguna app lee estas tablas: blast radius sobre el sistema corriendo = 0.
• wi-cli-venus blocked · 2026-08-20
  PURGA DETENIDA por el gate de backup (db-mba-l-cc, 2026-08-20). El dump del 08-13 existe y es legible (custom-format v1.16, TOC valido, las 4 tablas presentes) pero NO CUBRE: filas contadas del dump mismo (pg_restore --data-only, contando COPY reales, no el TOC) contra prod hoy: vehiculos_archive 6 vs 24161, vdc_archive 4 vs 23073, personas_archive 0 vs 46, entidades_archive 2 vs 28. Cobertura casi nula, no un hueco al margen. CAUSA: los triggers de archive disparan en CADA UPDATE (reference_vehiculos_archive_triggers_fire_on_every_update), asi que estas tablas crecieron sin parar despues del dump de las 12:26 - el dump las agarro casi vacias, temprano en su crecimiento. Purgar contra este dump destruiria ~24155/23069/46/26 filas con recuperacion posible solo para digitos simples. NECESITA: dump nuevo posterior al trabajo de esta noche, o decision explicita de Elazar de que cobertura parcial es aceptable para estas 4 tablas. El GO se dio sobre la premisa de que el backup cubria.
• wi-cli-venus commented · 2026-08-20
  PREMISA FALSA ENCONTRADA (db-mba-l-cc, 2026-08-20 05:09): los conteos del ticket son de DEV, no de PROD. Dump fresco tomado (2026-08-20-0508-movilba-prod.dump en /home/rob/movilba-db-work/prod-dump-20260820/) y cobertura verificada CONTRA EL DUMP MISMO: vehiculos_archive 45, vdc_archive 19, personas_archive 0, entidades_archive 1. PROD medido de forma independiente (no creyendole al ticket, que es lo que faltaba en la primera pasada): coincide EXACTO, 45/19/0/1. El dump cubre al 100%. Pero eso no se parece a los 24161/23073/46/28 del ticket. movilba_dev (10.9.10.54) medido directo: 24978/23521/50/30, dentro de la deriva normal de los numeros del ticket. EL GO SE ESCRIBIO CONTRA CONTEOS DE DEV APUNTANDO A UNA PURGA EN PROD. Las tablas de archive de PROD estan estaticas desde 2026-08-13 16:07:10 (max archived_at): nada se archivo en PROD en una semana, ni siquiera con las escrituras de esta noche (23/65/69). NO SE PURGO. La operacion tal como esta descrita no existe en PROD - alli hay 45/19/0/1. DECISION PARA ELAZAR: purga en PROD sobre los numeros REALES de PROD (45/19/0/1, trivial, dump ya lo cubre al 100%), o MOVILBA-11 en realidad era sobre DEV. Son operaciones muy distintas con riesgos muy distintos. Corolario: el bloqueo anterior ('el dump cubre 6 de 24161') tambien comparaba dump-de-prod contra conteos-de-dev - la conclusion de frenar fue correcta, el numero que la justificaba no.
• wi-cli-venus unblocked · 2026-08-20
  DIFERIDO por Elazar 2026-08-20. La premisa del ticket era falsa (conteos de DEV apuntando a purga en PROD) y en PROD hay 45/19/0/1 filas, no 24161/23073/46/28. No vale la pena contra el trabajo realmente encolado. El dump fresco de prod queda tomado y verificado, no se purgo nada.
• wi-cli-venus verified · 2026-08-21
  WRONG COMO ESTA ESCRITO, y ya se sabia; las cifras se movieron otra vez. Medido en prod por db-mba-l-cc 2026-08-21 08:14: vehiculos_archive 47, vdc_archive 22, personas_archive 0, entidades_archive 1. El ticket dice 24161/23073/46/28, que son y siempre fueron cifras de DEV. Crecio desde 45/19/0/1 de ayer porque el paquete de MOVILBA-104 archivo 2+3 filas hoy, asi que max(archived_at) es 07:29:53 de hoy y no un valor estatico. La operacion que el item describe no existe en prod. Dejarlo deferred o reescribirlo como item de DEV; NO agendarlo como esta.
• wi-cli-venus assigned · 6w ago
  db-mba-l-ca / db
• wi-cli-venus assigned · 4w ago
  db-mba-l-cc
• wi-cli-venus assigned · 4w ago
  db02-mba-l-cc / db
• wi-cli-venus descriptionChanged · 4w ago
  was: Copia de datos dev->prod ejecutada 2026-08-12 con GO de Elazar por bloque. Documentacion completa en docs/migrations/2026-08-12-copia-datos-dev-a-prod.md: decisiones de alcance, trabajo previo (MOBAAPI-638 identidades, vistas v_db_users_*, verificacion de atribuciones huerfanas=0, por que no se pudo TRUNCATE, cuenta system_import y saneamiento de creado_por), tablas copiadas con conteos antes/despues, reemplazo total de vehiculo_historial (solo filas vigentes), exclusiones y verificacion posterior (0 huerfanos en 13 caminos FK). PENDIENTE con GO propio: purga de las tablas *_archive en prod (vehiculos_archive 24161 + vdc_archive 23073 + personas_archive 46 + entidades_archive 28), unico lugar donde queda historial viejo visible.
• wi-cli-venus assigned · 3w ago
  db04-mba-l-ca
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 04:05 -03 — Status sweep limitation: The remaining archive-purge scope and safe legal disposition were not established; no archive deletion is authorized. BWI show and recent events were read; status unchanged and no DB write.
• coder03-mba-l-cc assigned · 1w ago
  researcher-mba-l-cc / solo
• researcher-mba-l-cc note · 1w ago
  2026-10-08T12:49:22-03:00 researcher-mba-l-cc re-measurement. No direct DB access in this lane (SELECT-only via db-lane agents per standing rule); last known count is db02/db04's 2026-09-18 figure (697/1298/0/1 across vehiculos_archive/vdc_archive/personas_archive/entidades_archive), itself already 20 days stale and known to keep growing every UPDATE on the live tables (same continuous-growth pattern confirmed between the 2026-08-20 and 2026-09-18 runs). Requested a fresh count via docs/reference/poblaciones-recurrentes.sql's archive_tablas_tamano query from db03 over hub DM; will relay the number once it lands, but since there is no fixed number to purge (it is whatever the count is at GO time, per Elazar's 2026-08-20 explicit deferral), a fresh count changes the magnitude, not the status. Dependency check: nothing in src/, tools/, or docs/reference/parque-movil-api/ reads these four *_archive tables directly (same consumer-search method as MOVILBA-122) - they exist only as trigger targets (INSERT on every UPDATE of the live table) with no application-level reader. Confirms the deferral's own premise: this is pure accumulated history with no live consumer, purge-only risk is data loss of old snapshots, not breaking a reader. Deferral remains correct: still no code work, still a single decision (scope + timing) plus a trivial DELETE once Elazar sets both. No change to status.