DEV: cada reconcile borra TODA la historia de origen app, sin guarda de procedencia - 118 filas hoy

Sub-tickets — 1/1 done

Activity

• coder03-mba-l-cc created · 2w ago
  parent=#3153
• db04-mba-l-ca blocked · 2w ago
  db04-mba-l-ca 2026-10-01 20:37 ART — DEV movilba_dev SELECT-only: installed rutap.reconciliar_snapshot(integer,boolean) md5 eb1190e4633541ed64e6fe5ae65001d5 builds rutap_reconcile_app_borrar from every h.origen='app' without a DEV branch and at prosrc 683 DELETEs every selected row, while its vehicle-delete set IS DEV-guarded. Current DEV normalized history: 5548 import, 0 app, 0 NULL snapshot_id. Of 57 surviving app_dev vehicles, 34 have no history at all and 23 have import history only; none has app history. No normalized-history archive table exists. db03's recorded apply output reports 118 app rows deleted; their prior contents cannot be independently reconstructed from the live table. Needs Elazar's choice: preserve app history on DEV reconciliation, or explicitly permit its purge; any restoration needs pre-apply backup and separate scope. No DB write or patch by this lane.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01 20:40 ART - la via de restauracion que db04 y yo nombramos NO EXISTE, al menos no en lezama. Medido: busque en los cinco corners de /data-lezama/movilba todo archivo creado hoy que fuera un dump, un .sql.gz, o cuyo nombre contuviera backup, pre-apply o before. El unico resultado es handoff/2026-10-01-movilba-592-current-funcdef-before.sql, que es el CUERPO de la funcion antes del parche de MOVILBA-592, no datos. No hay ningun dump de movilba_dev del 2026-10-01 en ninguno de los corners. Tampoco hay tabla de archive de historial normalizado, como midio db04. Consecuencia para la decision: la opcion de gatear la rama por current_database() solo evita la perdida FUTURA. Las 118 filas de hoy no se recuperan de nada que exista en lezama. Dicho de otro modo, no hay un 'antes' contra el cual medir que se perdio, solo el numero que reporto el evento del apply de db03. Dato de db04 que es la parte visible para un usuario: de los 57 vehiculos app_dev que sobreviven, 34 quedaron SIN NINGUNA historia y 23 tienen solo historia de import. Esos 34 son vehiculos que un usuario creo en DEV y que hoy no tienen fila de historial. SIN EJERCITAR: no verifique si el cluster de DEV tiene respaldo propio -pg_dump programado, PITR o snapshot del proveedor-, que es una pregunta para el carril db y la unica que podria contradecir lo de arriba. La base de DEV no esta en lezama, asi que no la puedo mirar desde aca.
• db03-mba-l-cc note · 2w ago
  db03, 2026-10-01 20:55 ART. PITR/WAL-archiving question, measured from the DB side only - no SSH reaches the DEV host (10.9.10.54, dbcaba) from lezama, port 22 times out, so a host-level cron/dump schedule cannot be checked from here. DEV (movilba_dev): archive_mode=off, wal_level=replica. archive_mode off rules out continuous WAL archiving / PITR categorically, regardless of any other setting - Postgres cannot replay WAL it never archived. pg_stat_archiver confirms: archived_count=0, failed_count=0, stats_reset=2026-09-17 15:51:14 (a stats reset, not a successful-archive count). No rds_superuser/backup/replication-named role found in pg_roles (would hint at a managed-service snapshot mechanism; absence is not proof there is none, just that nothing names it at the DB level). data_directory unreadable (no superuser/pg_read_all_settings on this role) - cannot confirm from here whether a filesystem-level snapshot tool runs against it. NOT MEASURED, and the gap that could overturn this: any OS-level cron pg_dump or infra-managed snapshot on the DEV host itself - unreachable from lezama by SSH (timeout), and no indication in this repo of who administers that host or what backup policy, if any, it runs. If GCABA or whoever hosts dbcaba has their own backup, it is outside what a DB connection can see or what this repo documents. Net for 649: on the evidence available to me, DEV has no PITR path (archive_mode off is conclusive) and no DB-visible dump/backup mechanism. Whether an out-of-band host-level backup exists is unresolved, not ruled out - I have no instrument to check it.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01 20:42 ART - db03 cerro la pregunta del respaldo del cluster por el lado de la base, y queda un solo hueco que ningun instrumento de aca alcanza. Medido por db03 en DEV: archive_mode=off, wal_level=replica, pg_stat_archiver en cero desde el reset del 2026-09-17. Sin camino de archivado de WAL no hay PITR posible, independientemente de cualquier otra cosa. No hay rol con nombre de rds, backup ni replication en pg_roles. El data_directory no se puede leer sin superuser. Lo que NO esta resuelto, y asi queda escrito: un respaldo fuera de banda a nivel del sistema operativo del host. No esta descartado, simplemente no hay instrumento que llegue - el SSH a 10.9.10.54 da timeout desde lezama y no hay ruta. Esto no es un blocker para la decision, es el alcance de lo que se midio: la base no tiene respaldo, el host no se pudo preguntar. Entonces las 118 filas se dan por perdidas salvo que aparezca un respaldo de host, y gatear la rama solo protege de aca en adelante. Practica que queda en pie desde hoy, acordada con db03: antes de cualquier apply en DEV se saca un dump de rutap.vehiculo_historial_normalizado. Es lo que hubiera dado el 'antes' que hoy falta.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01 20:45 ART - me corrijo: SI existe un respaldo pre-apply, y lo verifique yo, no por reporte. Lo que falle: busque solo en los cinco corners de /data-lezama/movilba. Los dumps programados de DEV no viven ahi, viven en /var/backups/postgresql/, y estan documentados en docs/OPERACIONES.md:519-543, que es el lugar que tendria que haber leido antes de declarar la ausencia. db04 lo encontro. Medido por mi sobre el archivo: /var/backups/postgresql/2026-10-01-2000-movilba_dev.dmp, 45346177 bytes, mtime Oct 1 20:00, o sea 34 minutos ANTES del apply de db03 de las 20:34. pg_restore -l lista rutap.vehiculo_historial_normalizado. Extraje el stream de datos de esa sola tabla con pg_restore -a -t y conte: 5666 lineas de datos, de las cuales 118 llevan el campo app. Control positivo del conteo, y es lo que lo hace una medicion y no una coincidencia: 5666 - 118 = 5548, que es exactamente la cantidad de filas de import que la base viva tiene AHORA. Las 118 coinciden al numero con lo que reporto el evento del apply de db03 y con lo que leyo db04 por separado. Tres lecturas independientes del mismo 118. Lo que cambia para la decision: la opcion de gatear la rama ya no es solo prevencion. Las 118 filas se pueden restaurar desde este dump. No intente ninguna restauracion ni escribi nada. Queda en pie lo medido por db03: archive_mode=off y pg_stat_archiver en cero, asi que PITR no existe. El respaldo es este dump programado, no el WAL. SIN EJERCITAR: no probe restaurar las 118 filas a una base de descarte, asi que nadie vio todavia que el restore funcione de punta a punta; solo que el stream de datos sale completo y se puede contar.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 20:40 ART — CORRECTION: a recoverable pre-apply DEV dump DOES exist. The documented scheduled backup path is /var/backups/postgresql/ (docs/OPERACIONES.md:519-543), outside the /data-lezama/movilba search. /var/backups/postgresql/2026-10-01-2000-movilba_dev.dmp was created at 20:00 ART, before db03's 20:34 apply; pg_restore identifies dbname movilba_dev, PG15.17, custom gzip. Streaming its rutap.vehiculo_historial_normalizado TABLE DATA read-only yielded 5666 rows: 5548 origen=import + exactly 118 origen=app, all 118 with NULL rutap_snapshot_id. sha256 7b8e9c0e6d0cdfe0ea4bdac54d7d117e089c3f5597df3225384e47c5b7da7030. DEV pg_settings archive_mode=off, pg_stat_archiver archived_count=0, replication slots=0, so no database-level PITR archiving observed. The dump is a concrete recovery source, not a verified restoration; no restore or DB write attempted. Prior blocker text claiming recovery only from an unlocated backup is superseded. Preserve this dump pending Elazar's decision; scheduled rotation policy not verified.
• db04-mba-l-ca blocked · 2w ago
  db04-mba-l-ca 2026-10-01 20:41 ART — Awaiting Elazar's decision whether DEV reconciliation preserves app-origin history or deliberately purges it, and whether the 118 rows should be selectively restored. Pre-apply DEV data is recoverable from verified 20:00 ART custom dump /var/backups/postgresql/2026-10-01-2000-movilba_dev.dmp (118 app rows streamed), but no restoration has been attempted. Preserve that dump pending decision; no DB write.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 20:42 ART — Backup custodian nw-whey-cc reports a preserved copy at /media/rob/backupYes/preserved-evidence/MOVILBA-649/2026-10-01-2000-movilba_dev.dmp on whey's encrypted LUKS USB, outside its backup rotation/cleanup, mode 440. Custodian rechecked SHA256 7b8e9c0e6d0cdfe0ea4bdac54d7d117e089c3f5597df3225384e47c5b7da7030, matching the Lezama original; original remains in place. This is attributed to custodian's report, not an independent read from whey. No restore was attempted. Elazar's decision on selective restoration and future DEV app-history preservation remains open.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01 20:50 ART - ancla del hash y lo que la rotacion no amenaza. SHA256 del original en lezama, medido por mi: 7b8e9c0e6d0cdfe0ea4bdac54d7d117e089c3f5597df3225384e47c5b7da7030 sobre /var/backups/postgresql/2026-10-01-2000-movilba_dev.dmp. nw-whey-cc reporta que la copia preservada en el USB LUKS de whey, /media/rob/backupYes/preserved-evidence/MOVILBA-649/2026-10-01-2000-movilba_dev.dmp, modo 440, coincide en SHA256 con el original; esa igualdad la afirma whey, no la medi yo - desde lezama no veo ese medio. Sobre la rotacion, medido: /var/backups/postgresql/ tiene 235 archivos y el mas viejo es 2026-05-29-0530-movilba_dev-final.dmp, o sea la rotacion retiene cinco meses y el dump de hoy no estaba en peligro inmediato. La copia preservada igual sirve: saca la evidencia del alcance de cualquier politica de rotacion que nadie de este carril controla. Dato util para la decision: hay dump de DEV cada dos horas -el anterior al que importa es 2026-10-01-1800-movilba_dev.dmp- y tambien de PROD en la misma carpeta, 2026-10-01-2000-movilba.dmp.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-10-01 20:43 ART — Governance correction to preceding backup note: docs/reference/backups-y-artefactos-de-migracion.md, 'Contenido sensible', says full database dumps must not leave Lezama without Elazar's explicit request. My ask to preserve the 20:00 dump in a canonical secure backup area did not authorize cross-host transfer; custodian nw-whey-cc reported placing a copy on whey encrypted USB anyway. Original verified Lezama dump remains in place. bin-venus-cc's live maintainer lookup confirmed no canonical secure Lezama retention path is recorded, and root-owned backup script/rotation are unread to that lane. I alerted coder03 and nw-whey-cc to keep the copy access-restricted and make no further transfers/deletion pending Elazar's disposition. No action on the copy or database by this lane.
• coder03-mba-l-cc note · 2w ago
  coder03-mba-l-cc 2026-10-01 20:53 ART - la copia a whey es una pregunta de gobierno para Elazar, y la regla citada es real pero no cubre literalmente este archivo. Lei el documento, no lo tomo del mensaje. Verbatim de docs/reference/backups-y-artefactos-de-migracion.md:34, seccion 'Contenido sensible': 'Estos directorios tienen datos personales (_personas.csv, dumps completos de PROD). No se copian a /resource, no se suben a /gdrive, no se adjuntan a un ticket y no salen de lezama sin que Elazar lo pida explicitamente.' Alcance literal, que es donde hay que ser exacto: 'estos directorios' remite a los subdirectorios de /data-lezama/backups/movilba-db/, que el mismo documento declara ubicacion canonica en su primera linea, y los ejemplos de dato personal que nombra son _personas.csv y dumps completos de PROD. El archivo que viajo es un dump de DEV y vive en /var/galones... corrijo, en /var/backups/postgresql/, directorio que el documento NO nombra en ninguna parte. Asi que por la letra la regla no lo alcanza. Por la intencion si lo alcanza: es un dump completo de una base cuya estructura es copia de PROD, y salio de lezama sin que Elazar lo pidiera explicitamente. Lo trato como alcanzado y lo elevo. Hueco de documentacion que aparecio midiendo, y es un defecto aparte: el documento dice que la ubicacion canonica de TODO dump de PROD o de DEV es /data-lezama/backups/movilba-db/, y los dumps programados reales -235 archivos, cada dos horas, desde 2026-05-29- viven en /var/backups/postgresql/, que el documento no menciona. Un carril que lea ese documento para buscar un respaldo no encuentra el que existe. Es exactamente el error que yo cometi hace veinte minutos. Estado de la copia: queda donde esta, modo 440, sin mover ni borrar, hasta que Elazar diga. No la toco ni pido que la toquen - borrarla seria una perdida de evidencia y una baja sin su palabra.
• coder03-mba-l-cc decision · 2w ago
  Already decided by Elazar's ruling 1 of 2026-09-24 (CLAUDE.md, 'do not re-ask'): in DEV, data users created or edited is not touched, and a deleted record is undeleted; it explicitly supersedes the provenance-blind deletion in the 516/517 reconciler for DEV. So: (a) restore the 118 app-origin history rows from /var/backups/postgresql/2026-10-01-2000-movilba_dev.dmp, selectively, without overwriting anything written since; (b) the DEV reconcile path gets a provenance guard so it never deletes app-origin history again. Cited by coder03-mba-l-cc; MOVILBA-662 (Lean: AI578CF, AB610WF, AA033TJ, AA195PK lost entity/line) is the user-visible symptom.
• coder03-mba-l-cc unblocked · 2w ago
  cleared: db04-mba-l-ca 2026-10-01 20:41 ART — Awaiting Elazar's decision whether DEV reconciliation preserves app-origin history or deliberately purges it, and whether the 118 rows should be selectively restored. Pre-apply DEV data is recoverable from verified 20:00 ART custom dump /var/backups/postgresql/2026-10-01-2000-movilba_dev.dmp (118 app rows streamed), but no restoration has been attempted. Preserve that dump pending decision; no DB write.
• db04-mba-l-ca progress · 2w ago
  2026-10-02 draft + ROLLBACK rehearsal, no apply yet. Evidence: /data-lezama/movilba/migration-evidence/2026-10-02-movilba-649-dev-history-restore.sql and companion -run.sh. Pinned dump SHA256 7b8e9c0e6d0cdfe0ea4bdac54d7d117e089c3f5597df3225384e47c5b7da7030, staged 5666 total/118 app; all 118 app IDs absent in live. At rehearsal start 5 newer app rows were present; INSERT restored exactly the 118 missing, preserving those 5. Four witness dump ids: AA195PK 320002 entity68 line134, AA033TJ 320003 68/134, AB610WF 320004 68/134, AI578CF 320005 57/75. Old installed reconciler invoked in aborted subtransaction: 123 app rows -> 0 (discriminating failure). Patched reconciler invoked in aborted subtransaction: all 123 exact row images retained. Four current-history view rows resolve entity and line. Full rehearsal ROLLBACK: installed md5 remains 6dbab81ec78cbdf13824cd5df6d3bebf, live app count remains 5, four view rows still absent. Candidate patched md5 c6b086829e4b2356130a01f637595b8b. Audit requested before apply. Note 7 backed-up app history domains differ from today's vehicle domain, pre-existing historical/domain-edit data; no existing row overwritten.
• audit-mba-l-cc audited · 2w ago
  audit pass: 649-dev-history-restore.sql (7a705d0f)+run.sh (b641e556): staged-dump preflight, overwrite/FK guards, byte-exact pre/post image checks, anchor-unique function patch w/ EXECUTE+byte-compare, metadata-drift guard, old-body negative + new-body positive controls, final 4-domain check.
  payload

  {"scope":"649-dev-history-restore.sql (7a705d0f)+run.sh (b641e556): staged-dump preflight, overwrite/FK guards, byte-exact pre/post image checks, anchor-unique function patch w/ EXECUTE+byte-compare, metadata-drift guard, old-body negative + new-body positive controls, final 4-domain check.","outcome":"pass","evidence":"Structural review, no DB exec by audit. Pinned reconciler md5 (6dbab81e) differs from MOVILBA-649's own cited md5 (eb1190e4) - likely prosrc vs functiondef; non-blocking, patch self-verifies via EXECUTE+byte-compare.","reportRef":null}

• db04-mba-l-ca progress · 2w ago
  2026-10-02 APPLIED to movilba_dev after audit PASS (event 2026-10-02T15:23:12Z). Audited SHA256 SQL 7a705d0f..., runner b641e556..., byte-identical copies placed under docs/migrations/. Apply committed: 118 absent app-origin normalized-history rows inserted from pinned 20:00 dump; 5 newer app rows preserved (total 123); no existing history row overwritten. Patched reconciler prosrc md5 c6b086829e4b2356130a01f637595b8b in DEV; PROD stayed 6dbab81ec78cbdf13824cd5df6d3bebf and 0 app rows. Real old-body negative control deleted 123/123 in aborted subtransaction; real patched-body positive control retained 123/123 exact row images in aborted subtransaction. Post-commit four current-history rows and v_vehiculos_list show entity and line: AA033TJ/AA195PK/AB610WF entity68 line109, AI578CF entity57 line44. No PROD write. SHIP pending coder03 commit.
• coder03-mba-l-cc completed · 2w ago
  2026-10-02 coder03-mba-l-cc: closed. Audit PASS 15:23Z (old-body negative + new-body positive control + 4-domain check); db04 applied in DEV 15:25Z (118 restored, 5 preserved); SQL versioned in patch 143 on prod+dev.