go install) moves forward onto tested
code. The 1.2.x-only features (work leases, the events journal, sync
federation, the HTTP API server, provenance events) are not in v1.2.2; they
will return in a properly tested release.
The catch: running the v1.2.1 binary even once (any command, including
bd list) migrated your local database schema from v53 to v65. The v1.2.2
binary speaks schema v53, so on such a database it stops with:
Am I affected?
Only if you both ran v1.2.1 at least once and see the schema-mismatch error above with v1.2.2 (or any 1.1.x binary). Users who upgraded but never ranbd, and users whose workspace has a Dolt remote configured (the
remote-migrate gate blocked silent migration), are typically not affected.
Recommended fix: roll the schema cursor back
The v1.2.x migrations were written to be replay-safe after a cursor rollback, so this is reversible and a later, properly tested 1.2.x upgrade will work normally afterwards.- Upgrade every machine and clone to v1.2.2 first. A leftover v1.2.1 binary that touches the database will silently re-migrate it.
-
Stop anything using the database: close running
bdprocesses; in server mode also runbd dolt stop. -
Take a backup copy of the workspace database:
-
Roll the cursor back with the Dolt CLI
(any recent
doltrelease works; nodolt configsetup is needed — the command carries its own author). The database directory is.beads/embeddeddolt/<db>(embedded mode, the default) or.beads/dolt/<db>(server mode):(If this reports there is nothing to commit, the step was already done — safe to continue.) -
Run any
bdcommand from the workspace. It should work with no warnings and noBD_IGNORE_SCHEMA_SKEWneeded.
Optional: restore audit-event versioning
One v1.2.x migration moved theevents audit table off Dolt’s versioned
plane, and after the cursor rollback the 1.1 line keeps writing audit
events without versioning or syncing them (everything else syncs
normally). If you rely on the versioned audit trail, re-track the table
from the same database directory:
Stopgap: keep working before you recover
If you needbd this minute, the skew guard has an escape hatch:
What recovery leaves behind
Data the accidental release wrote into 1.2.x-only structures stays in the database but is unused by the 1.1 line: work-lease state (ephemeral, 5-minute horizon), events-journal rows (feature was off by default), provenance rows (only written by an explicit new command), andstorage_class markers. None of it blocks a future 1.2.x upgrade, which
will simply resume using it.
Alternative: full rollback via Dolt history
If you want the database history itself restored to its pre-migration state (the cursor rollback keeps the migration commits in history), the v1.2.1 migrator made one labeled Dolt commit per migration (schema: apply migration 0054_... through 0065_...), so the
pre-migration commit is easy to find. The safe sequence is: export with
the v1.2.1 binary (bd export --all -o backup.jsonl), stop everything and
copy .beads aside, dolt reset --hard <pre-migration-commit> in the
database directory, install v1.2.2, then bd import backup.jsonl.
Caveats: issues deleted after the upgrade come back (import cannot
re-delete), and audit events recorded while on v1.2.1 are lost. Most users
should prefer the cursor rollback above.