Skip to content

v2.6.1 — migration metadata hotfix (FLEXIBLE object fields)

Choose a tag to compare

View all tags
@acidkill acidkill released this 07 Jul 14:46
· 208 commits to main since this release
v2.6.1
1b20c5a
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Critical hotfix for 2.6.0. The v7→v8 synapse→RELATE migration silently dropped every synapse with non-empty metadata, so it could not complete on a real database. No data was lost (originals are always kept in synapse_migration_backup and the source data is untouched), but 2.6.0 upgrades on an existing brain aborted. Upgrade straight to 2.6.1.

Root cause

The v8 synapse RELATION table is SCHEMAFULL, but its metadata field was a plain TYPE object — which on a SCHEMAFULL table rejects any undefined nested key ("Found field 'metadata._dedup', but no such field exists"). Every synapse carrying nested metadata was skipped as "data loss" and the migration aborted at verification. The same gap existed on every other SCHEMAFULL table with a metadata/config object field (neuron, fiber, brain, typed_memory, source, alerts, brain_versions) — a latent bug on fresh databases, where any nested-metadata write would be rejected.

Fixed

  • All object fields are now TYPE object FLEXIBLE (synapse + the seven other tables), so nested metadata/config is accepted and preserved.
  • The migration's converting phase now always rebuilds the RELATION table from the complete backup on entry (including on resume), so a database left half-converted by a 2.6.0 attempt recovers every skipped row.
  • Regression test seeds a synapse with nested metadata and asserts it survives the migration.

Verified

  • Migrated a copy of a real brain — 174,592 synapses, 0 skipped, 150,430 nested-metadata objects preserved, all counts identical, synapse is native RELATION.
  • make verify green: 5800 passed, coverage 68.89%.

Upgrade

If you are on 2.6.0 (or upgrading from an older release): back up the surrealdb_data volume, then pip install -U surreal-memory / docker compose pull && up -d. First connect auto-migrates losslessly. Verify with smem doctor --synapse-migration status.

Full changelog: https://github.com/acidkill/surreal-memory/blob/main/CHANGELOG.md#261--2026-07-07

Assets 4
Loading