2026-08-31 · run 2026-08-31-26.7.1-to-26.7.3-3

26.7.1 → 26.7.3 (run 3, rollback exercised)

Environment

Identical to run 2 (same baseline-26.7.1-kitchen-sink-1k).

Procedure

./bin/restore.sh baseline-26.7.1-kitchen-sink-1k   # reset to 26.7.1
./bin/upgrade.sh 26.7.3                            # -> 26.7.3, backup taken
./bin/restore.sh pre-upgrade-26.7.1-to-26.7.3-20260831T213925Z   # rollback

Timings

Outcome

• Upgrade reached ready, 0 changesets, index audit 119/119
• Rollback restored the pre-upgrade dump and returned to 26.7.1
• No re-migration: schema stamp 26.7.1 before and after the recreate
• Data intact post-rollback: 1,000 users, 11 clients

Breakage observed

restore.sh postgres rollback path was broken (model_version: command not found)

• Symptom: on the postgres engine, restore.sh aborted at SCHEMA=$(model_version) — the function is defined only in the mysql|mariadb branch of the first case "$ENGINE", but is called unconditionally for all engines.
• Evidence: ./bin/restore.sh: line 118: model_version: command not found; the DB was restored (schema at 26.7.1) but the script exited before the --force-recreate and before the re-migration check.
• Cause: regression from the multi-engine refactor — the postgres model_version definition was dropped.
• Fix: re-added the postgres model_version() (with the S13 search_path care) to the * branch. Fix is in bin/restore.sh.
• Would this hit a customer? Only our own lab tooling — but it means the rollback verification gate had been silently non-functional for postgres. This run is the first to actually exercise it since the refactor.

Rollback

• Exercised this run? yes
• Method: pg_dump -Fc restore (dropdb + createdb + pg_restore --no-owner), then --force-recreate at 26.7.1
• Time to restore: ~30s at 1k users
• Data loss / divergence: none (1,000 users, 11 clients intact)
• Verdict: rollback IS a point-in-time restore; no schema downgrade, no re-migration. Confirmed available on this path.