Edit Issue - .issue.db

Title *

Description

EARS: When migrations-entrypoint.sh runs against an empty database, the migrations service shall apply engine, jumper and product migrations and exit 0.

Found by the #918 CI fresh-install step (emulated in ci-python:3.13, PostgreSQL 16 and 18, empty database, migretti 0.10.0). Order is the one docker/migrations-entrypoint.sh uses: engine root, mark jumper_initial, jumper root, product root.
- Engine root applies 101 migrations, the last being 01M514J6GN9S42SQK3YW8GKEVP drop_rag_embedding_cache.
- Jumper root then fails: 01KGX8TA6RZGZFE4RYVNGBMP78, 01KGX9TA6..., 01KGXATA6..., 01KGXBTA6... 'sort before already-applied 01M514J6GN9S42SQK3YW8GKEVP'; mg refuses without --allow-out-of-order.
- Product root fails the same way on 01KYW41EEMWXYGD0EX1VRCN4B3 oidc_session_backchannel_logout (19 product-only ids, several older than 01M514...).
Production never hit this because its database applied these migrations over time. A rebuild from an empty database (disaster recovery, a new environment, docker compose down -v) stops at the jumper root today.
The 92 ids shared between roots are byte-identical. Applying the union of the three roots in id order (skipping 01KGX7TA6 jumper_initial, which the entrypoint marks applied) works up to the pgvector migration.
Options for the owner: run mg apply --allow-out-of-order for the jumper and product roots after review, or merge the roots into one ordered set. The CI step 'fresh install in the production entrypoint order' stays red until this is fixed.

Due Date (YYYY-MM-DD)

Tags (comma separated)

Related Issues (IDs)

Enter IDs of issues related to this one. They will be linked as 'related'.

Edit Issue #971