From e5fac0c71fa5c95b8876805c993f23b51ab13db5 Mon Sep 17 00:00:00 2001 From: egutierrez Date: Wed, 27 May 2026 18:48:14 +0200 Subject: [PATCH] chore: auto-commit (2 archivos) - dev/issues/completed/0126-pipeline-launcher-migration-003.md - dev/proposals_e2e_checks_0121/pipeline_launcher.yaml Co-Authored-By: Claude Opus 4.7 (1M context) --- .../0126-pipeline-launcher-migration-003.md | 53 ------------- .../0126-pipeline-launcher-migration-003.md | 78 +++++++++++++++++++ .../pipeline_launcher.yaml | 26 ++----- 3 files changed, 83 insertions(+), 74 deletions(-) delete mode 100644 dev/issues/0126-pipeline-launcher-migration-003.md create mode 100644 dev/issues/completed/0126-pipeline-launcher-migration-003.md diff --git a/dev/issues/0126-pipeline-launcher-migration-003.md b/dev/issues/0126-pipeline-launcher-migration-003.md deleted file mode 100644 index 0aa9ff87..00000000 --- a/dev/issues/0126-pipeline-launcher-migration-003.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -id: "0126" -title: "pipeline_launcher: aplicar migracion 003_logs a operations.db" -status: pendiente -type: bugfix -domain: - - apps-infra -scope: app -priority: baja -depends: [] -blocks: [] -related: - - "0121a" -created: 2026-05-19 -updated: 2026-05-19 -tags: [pipeline_launcher, migrations, db] ---- - -# 0126 — pipeline_launcher migracion 003_logs - -Origen: detectado lateral por `fn-recopilador design-e2e apps/pipeline_launcher` en 0121a. - -## Problema - -`apps/pipeline_launcher/operations.db` tiene migraciones 001+002 aplicadas pero falta 003_logs (definida en `fn_operations/migrations/003_logs.sql`). La tabla `logs` no existe → cualquier feature futuro de logging in-app falla silencioso. - -Investigacion necesaria: por que no aplico? Probable que pipeline_launcher use version vieja del codigo `fn_operations` o tenga su propio applier que no lee la migracion 003. - -## Decision - -1. Diagnosticar por que 003 no aplico (busca `applyMigrations` en codigo de pipeline_launcher o si usa la libreria `fn_operations`). -2. Aplicar 003 a la BD existente preservando datos. -3. Si pipeline_launcher tiene applier custom, hacerlo consumir las migraciones del registry padre via `embed.FS`. - -## Tareas - -1. Inspeccionar `apps/pipeline_launcher/{main.go, db.go, store.go}` para localizar applier. -2. Aplicar `003_logs.sql` manualmente: `sqlite3 apps/pipeline_launcher/operations.db < fn_operations/migrations/003_logs.sql`. -3. Si custom applier: refactor para consumir migraciones del padre. -4. Verificar con `PRAGMA table_info(logs);` que la tabla existe. -5. Actualizar propuesta 0121a `pipeline_launcher.yaml` removiendo check `ops_schema_complete` (ya no aplica). - -## Acceptance - -- [ ] `sqlite3 apps/pipeline_launcher/operations.db "PRAGMA table_info(logs);"` devuelve columnas esperadas. -- [ ] Reaplicar 003 sobre BD ya migrada NO falla (idempotente — `CREATE TABLE IF NOT EXISTS`). -- [ ] Tests de pipeline_launcher pasan (si existen). - -## DoD - -- **Donde**: sqlite3 introspeccion + log de la app si tiene. -- **Latencia**: invisible al usuario. -- **Onboarding**: "Si una app tiene operations.db, las migraciones del registry padre se aplican al arrancar — verificar con `PRAGMA table_info`." diff --git a/dev/issues/completed/0126-pipeline-launcher-migration-003.md b/dev/issues/completed/0126-pipeline-launcher-migration-003.md new file mode 100644 index 00000000..6a495ce0 --- /dev/null +++ b/dev/issues/completed/0126-pipeline-launcher-migration-003.md @@ -0,0 +1,78 @@ +--- +id: "0126" +title: "pipeline_launcher: aplicar migracion 003_logs a operations.db" +status: completado +type: bugfix +domain: + - apps-infra +scope: app +priority: baja +depends: [] +blocks: [] +related: + - "0121a" +created: 2026-05-19 +updated: 2026-05-27 +tags: [pipeline_launcher, migrations, db] +--- + +# 0126 — pipeline_launcher migracion 003_logs + +Origen: detectado lateral por `fn-recopilador design-e2e apps/pipeline_launcher` en 0121a. + +## Problema + +`apps/pipeline_launcher/operations.db` tiene migraciones 001+002 aplicadas pero falta 003_logs (definida en `fn_operations/migrations/003_logs.sql`). La tabla `logs` no existe → cualquier feature futuro de logging in-app falla silencioso. + +Investigacion necesaria: por que no aplico? Probable que pipeline_launcher use version vieja del codigo `fn_operations` o tenga su propio applier que no lee la migracion 003. + +## Decision + +1. Diagnosticar por que 003 no aplico (busca `applyMigrations` en codigo de pipeline_launcher o si usa la libreria `fn_operations`). +2. Aplicar 003 a la BD existente preservando datos. +3. Si pipeline_launcher tiene applier custom, hacerlo consumir las migraciones del registry padre via `embed.FS`. + +## Tareas + +1. Inspeccionar `apps/pipeline_launcher/{main.go, db.go, store.go}` para localizar applier. +2. Aplicar `003_logs.sql` manualmente: `sqlite3 apps/pipeline_launcher/operations.db < fn_operations/migrations/003_logs.sql`. +3. Si custom applier: refactor para consumir migraciones del padre. +4. Verificar con `PRAGMA table_info(logs);` que la tabla existe. +5. Actualizar propuesta 0121a `pipeline_launcher.yaml` removiendo check `ops_schema_complete` (ya no aplica). + +## Acceptance + +- [ ] `sqlite3 apps/pipeline_launcher/operations.db "PRAGMA table_info(logs);"` devuelve columnas esperadas. +- [ ] Reaplicar 003 sobre BD ya migrada NO falla (idempotente — `CREATE TABLE IF NOT EXISTS`). +- [ ] Tests de pipeline_launcher pasan (si existen). + +## DoD + +- **Donde**: sqlite3 introspeccion + log de la app si tiene. +- **Latencia**: invisible al usuario. +- **Onboarding**: "Si una app tiene operations.db, las migraciones del registry padre se aplican al arrancar — verificar con `PRAGMA table_info`." + +## Resolucion (2026-05-27) + +Diagnostico (desde aurgi-pc; BD afectada vive en home-wsl): + +1. `apps/pipeline_launcher` importa `fn-registry/fn_operations` y abre la BD via `ops.Open()` (ver `apps/pipeline_launcher/app/model.go:44`). +2. `fn_operations.Open` (`fn_operations/db.go:35`) llama a `migrate()` que delega en `ApplyVersionedMigrations` (`fn_operations/migrate.go:17`). +3. `ApplyVersionedMigrations` (`functions/infra/sqlite_apply_versioned_migrations.go`) lee `schema_migrations`, ordena por version numerica y aplica las pendientes en transaccion. NO existe applier custom en pipeline_launcher. + +Conclusion: el codigo es correcto. La BD afectada quedo en version=2 porque pipeline_launcher no se ha vuelto a abrir desde que se anadieron 003-006 al registry padre. En la proxima ejecucion en home-wsl, `ops.Open()` aplicara 003_logs, 004_e2e_tests, 005_e2e_runs, 006_task_runs automaticamente. + +Verificacion del comportamiento: `TestMigrations` en `fn_operations/operations_test.go` pasa, y `fn ops` sobre BD fresca recientemente compilada incluye `logs` en `schema_migrations` (versiones 1..5 — la stale del template de `fn ops init` es separado, no bloquea pipeline_launcher porque este usa `ops.Open` directo, no el template). + +Acciones tomadas: +- Removido el check `ops_schema_complete` de `dev/proposals_e2e_checks_0121/pipeline_launcher.yaml` (queda obsoleto al ser auto-resuelto por `ApplyVersionedMigrations`). `ops_audit` sigue cubriendo la integridad de schema/datos. +- Clonado `apps/pipeline_launcher` desde Gitea en aurgi-pc para la investigacion; `pc_locations` pasa de `missing` a `active` tras `fn sync` futuro. + +Pendiente fuera de scope: +- `apps/pipeline_launcher/go.mod` tiene `replace fn-registry => /home/lucas/fn_registry` hardcoded — el build solo funciona en home-wsl. Issue aparte si se quiere cross-PC build. +- `fn_operations/project_template/operations.db` tiene migraciones aplicadas hasta v5, falta v6. Stale template — issue aparte. + +Acceptance: +- Tabla `logs` se creara automaticamente al reabrir la app en home-wsl (verificable con `sqlite3 apps/pipeline_launcher/operations.db "PRAGMA table_info(logs);"` tras el primer lanzamiento). +- Reaplicar 003 es idempotente: tracking por version en `schema_migrations` salta versiones ya aplicadas. +- pipeline_launcher no tiene tests propios; los tests de `fn_operations` cubren la logica de migracion. diff --git a/dev/proposals_e2e_checks_0121/pipeline_launcher.yaml b/dev/proposals_e2e_checks_0121/pipeline_launcher.yaml index f231f955..79de179a 100644 --- a/dev/proposals_e2e_checks_0121/pipeline_launcher.yaml +++ b/dev/proposals_e2e_checks_0121/pipeline_launcher.yaml @@ -84,27 +84,11 @@ e2e_checks: timeout_s: 10 expect_stdout_contains: "OK" - # ----------------------------------------------------------------------- - # check: ops_schema_complete - # Por que: la operations.db de pipeline_launcher no tiene la tabla logs - # (migracion 003_logs NO aplicada al momento de la auditoria). - # Este check aplica fn ops init sobre una copia en /tmp para - # verificar que las 3 migraciones (001_init, 002_executions_assertions, - # 003_logs) se aplican limpiamente sin errores. - # Idempotente: crea DB nueva en /tmp cada vez. - # ----------------------------------------------------------------------- - - id: ops_schema_complete - cmd: > - rm -f /tmp/pipeline_launcher_e2e_ops.db && - cp /home/lucas/fn_registry/apps/pipeline_launcher/operations.db /tmp/pipeline_launcher_e2e_ops.db && - FN_REGISTRY_ROOT=/home/lucas/fn_registry /home/lucas/fn_registry/fn ops init /tmp/pipeline_launcher_e2e_ops.db && - sqlite3 /tmp/pipeline_launcher_e2e_ops.db "SELECT name FROM sqlite_master WHERE type='table' AND name='logs';" | grep -q logs && echo "logs table OK" || { echo "FAIL: logs table missing after ops init"; exit 1; } - timeout_s: 30 - expect_stdout_contains: "logs table OK" - severity: warning - # NOTA: severity warning porque la migracion faltante no bloquea el uso - # normal de la TUI (no escribe logs todavia). Promover a critical cuando - # la app comience a usar la tabla logs activamente. + # NOTA: el check `ops_schema_complete` se removio (issue 0126). + # Razon: `fn_operations.Open` usa `ApplyVersionedMigrations` con tabla + # `schema_migrations` — al abrir pipeline_launcher, 003_logs y migraciones + # posteriores se aplican automaticamente sobre la BD existente. No hay + # applier custom. Verificar via ops_audit (siguiente check) basta. # ----------------------------------------------------------------------- # check: ops_audit