Upgraden vanaf legacy SQLite-shards

Bij opstarten herstelt de plugin onderbroken re-embed-swaps, zet libSQL DiskANN-indexen om naar de huidige Turso-engine, en verifieert of upgradeert daarna het legacy shard-schema. Engineconversie draait ook wanneer een store al een voltooide legacy-migratiemarker heeft, en behoudt opgeslagen vectoren zonder opnieuw te embedden. Elke geconverteerde database wordt geback-upt als <database>.pre-tursodb-<timestamp>.bak.

Op macOS en Linux kunnen meerdere OpenCode-sessies hetzelfde storagePath delen via Turso’s experimentele multiprocess_wal (elk proces moet dezelfde modus gebruiken — herstart alle sessies na een upgrade). Op Windows weigert de engine die flag, dus slechts één OpenCode-sessie kan tegelijk de geheugendatabases bezitten.

tursoMultiprocessWal: false opent in single-owner-modus: andere processen falen dan met database is locked in plaats van de store te delen. Dat is veiliger als niet-plugin-tools dezelfde bestanden aanraken, omdat een schrijvend vreemd SQLite-proces de WAL-index van Turso stale maakt en de eigen volgende write stil verloren gaat. tursoAutoHeal (standaard true) verplaatst de index-sidecars -shm/-tshm van een store naar storagePath/recovery/<db>-<timestamp>/ en probeert één keer opnieuw wanneer een open faalt door een stale WAL-index, na verificatie van een kopie van de hoofddatabase. Een niet-lege -wal wordt nooit verplaatst, zodat gecommitte maar nog niet gecheckpointte transacties overleven; alleen een ontbrekende of 0-byte -wal wordt verwijderd. Gelijktijdige sessies serialiseren healing via storagePath/recovery/<db>.lock.

Bij de eerste start na een upgrade migreert opencode-mem bestaande memory-shard-databases automatisch naar het native Turso/libSQL-vectorformaat:

• Elke shard wordt vóór herschrijven geback-upt als <shard>.db.legacy.bak
• Voortgang wordt per shard bijgehouden in <shard>.db.turso-migrate.json
• Een globale marker .turso-migrated wordt pas geschreven nadat alle shards succesvol zijn geverifieerd
• Normale inserts en deletes maken een voltooide shard-migratie niet ongeldig; bij opstarten controleert de plugin nog steeds of vectoren leesbaar zijn en bij de opgeslagen dimensies passen
• Draai geen meerdere OpenCode-instanties tegen hetzelfde storagePath tijdens migratie; een lockbestand (.turso-migrate.lock) voorkomt gelijktijdige migratie
• Handmatige dimensiemigraties gebruiken .turso-operation.lock; andere pluginprocessen weigeren nieuwe memory-writes tot de migratie klaar is
• Locks verlopen na 30 minuten zonder voortgangs-timestamp-update (of bestandswijzigingstijd als die timestamp ontbreekt), ook als het bezittende proces nog leeft. Deze lease gebruikt wandkloktijd: een voorwaartse kloksprong groter dan 30 minuten kan een lopende operatie vroeg laten verlopen; een achterwaartse stap of toekomstgedateerde lock kan een inerte lock verlengen. Locks dragen een unieke acquisition-id, en stale cleanup verwijdert alleen het precies geïnspecteerde bestand. Migraties sturen heartbeats en breken af als ze merken dat ownership verloren is. Stale-lock-cleanup wordt gelogd voor diagnose.

Als migratie wordt onderbroken, hervat de volgende start automatisch vanuit de backup.

Als een shard incompatibel wordt (bijvoorbeeld na wijziging van embeddingDimensions), worden writes geblokkeerd en blijft de originele database onaangeroerd. Gebruik de re-embed-migratie in de web-UI om een vervanging te bouwen en te verifiëren voordat deze wordt omgewisseld. De vorige shard blijft beschikbaar als <shard>.db.pre-reembed-<pid>-<timestamp>.bak.