fn_registry/dev/issues/completed/0126-pipeline-launcher-migration-003.md

id, title, status, type, domain, scope, priority, depends, blocks, related, created, updated, tags

id	title	status	type	domain	scope	priority	depends	blocks	related	created	updated	tags
0126	pipeline_launcher: aplicar migracion 003_logs a operations.db	completado	bugfix	apps-infra	app	baja			0121a	2026-05-19	2026-05-27	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/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.