fix(store): detect 1.18→2.x migrated stores as v2

[DGVY]

Problem

A store that went through OpenCode's official 1.18 → 2.x in-place upgrade is misclassified as a v1 store, and the v2 fail-closed assert then refuses generation-specific access on every read:

[magic-context] v2 refuseIfUnsafe warn: OpenCode store generation mismatch at
~/.local/share/opencode/opencode.db: expected v2, found v1; refusing
generation-specific database access

The official migration keeps the retired message/part tables beside the new session_v2/session_message ones (tens of thousands of legacy rows on a long-lived install), so detectOpenCodeStoreGeneration — keyed on v1-table presence — reads every migrated store as v1.

Impact (observed on opencode 2.0.5/2.0.8 hosts)

Every prompt interrupts within ~20 ms of submission: the plugin's session hook fails during setup, the host swallows the error (zero server-side log lines at the moment of death), and no model call is ever made. Sessions show user → idle(interrupted) with no assistant turn. A clean-install store on the same host version works fine, which makes this look host-version-specific and sent us chasing opencode regressions for a long while before the mismatch warn surfaced in debug logs.

Fix

session_v2 is an unambiguous v2 signal — OpenCode 1.18.x never creates it while every 2.x store does — so prefer it over the v1-message heuristic:

if (tables.has("session_v2")) return "v2"   // new, strongest signal
if (tables.has("message") && tables.has("part")) return "v1"
...

Pure 1.18.x stores (no session_v2) keep reading as v1; the pinned live-1.18 fixture test is unchanged and still passes.

Tests

• New: a migrated store (message+part+session+project+session_v2+session_message) detects as v2, asserts v2 fine, and asserts v1 throws.
• Existing: 492 tests across packages/plugin/src/shared + src/v2 pass, 0 fail.

Related note

The 0.42.6 v2 lane also calls context.model.list() directly (pre-catalog shape), which throws on opencode 2.0.3 hosts whose plugin context predates the model domain — same swallowed-error instant-interrupt symptom. Main already uses context.catalog.model.list, so that one looks resolved on main; mentioning it here since the two combined made 0.42.6 fatal on 2.0.3.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Summary by cubic

Fixes store generation detection so stores migrated through OpenCode's official 1.18 → 2.x upgrade are treated as v2 instead of v1, and keeps the legacy tool-owner backfill working on those stores.

Bug Fixes

• session_v2 is now the strongest v2 signal; pure 1.18.x stores without it still detect as v1.
• The backfill now checks for the v1 message tables directly instead of asserting a v1 store, so migrated stores are backfilled and pure v2 stores fail fast with a clearer message.
• Adds a migrated-store test covering v2 detection, v2 assert pass, and v1 assert throw.
• Restores bun.lock to the upstream resolution so bun install --frozen-lockfile passes.

^{Written for commit 145eb11. Summary will update on new commits.}

Confidence Score: 4/5

The store-detection and backfill fixes appear sound, but the PR is not yet safe to merge because the lockfile still depends on an unconfigured third-party registry.

Findings

1.  Third-party registry breaks installs ▶
2.  Migrated stores skip backfill ▶

Summary

The PR corrects OpenCode store-generation detection and its related legacy owner-backfill behavior.

• Treats session_v2 as the strongest v2 schema signal, including when migrated stores retain v1 tables.
• Allows the owner backfill to process any store that still has the legacy message and part tables.
• Adds regression coverage for generation detection and assertions on a migrated schema.
• The earlier third-party registry change in bun.lock remains outstanding.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Inspect OpenCode schema] --> B{session_v2 exists?}
    B -->|Yes| C[Classify as v2]
    B -->|No| D{message and part exist?}
    D -->|Yes| E[Classify as v1]
    D -->|No| F{session_message exists?}
    F -->|Yes| C
    F -->|No| G[Empty or unknown]
    C --> H{Legacy message tables remain?}
    E --> H
    H -->|Yes| I[Run best-effort tool-owner backfill]
    H -->|No| J[Skip backfill and use lazy adoption]

Loading

_{Reviews (2) · Last reviewed commit: "fix(backfill): accept migrated stores in..."}

Closes #489

[cortexkit-ci]

Waiting for design-approved on #489.

This PR needs a linked issue with the design-approved label before it can be reviewed or merged. Add Closes #<issue> to the description; a maintainer will apply the label on the issue once the design is agreed. Trivial fixes: a maintainer can add the trivial label to this PR instead.

[greptile-apps]

Third-party registry breaks installs

The regenerated lockfile pins every dependency tarball to registry.npmmirror.com, although the repository has no committed configuration for that registry. CI uses bun install --frozen-lockfile, so an unavailable or blocked mirror will break installs across the project. Restore the default resolution entries or configure this registry as an intentional, separate change.

[greptile-apps]

Migrated stores skip backfill

Prioritizing session_v2 also affects runToolOwnerBackfill. Migrated stores retain the legacy message and part tables that this backfill reads, but this line now classifies them as v2 before the backfill's hard-coded v1 assertion. The assertion therefore throws during a normal database open, leaving eligible legacy tool-owner rows to the slower lazy-adoption fallback instead of completing the intended boot-time backfill. The backfill must explicitly accept migrated stores whose legacy tables remain.

[DGVY]

Both review findings addressed in 145eb11:

• bun.lock: restored to the upstream resolution (the mirror-pinned regeneration came from my local install; CI's --frozen-lockfile would indeed break).
• backfill: runToolOwnerBackfill no longer asserts a single generation — it now gates on the new hasV1MessageTables(db, "oc_backfill") helper, i.e. exactly what it reads. Migrated stores (v2 + legacy tables) backfill normally; pure v2 stores fail fast with a clearer "no v1 message tables; nothing to backfill" message.

Verified: shared+v2+features suites — 2197 pass, 1 fail where the failing test (transformers-node-wasm fixture, builds a model from network) also fails on unmodified master under the same sandbox, so it is unrelated to this change.

[DGVY]

Linked design rationale in #489 (gate now reads "Waiting for design-approved on #489"). Happy to iterate there if any decision needs discussion — D1/D2 and the rejected alternatives are laid out per-decision. If this qualifies as trivial in your judgment, the trivial label on the PR works too.

[magic-alfonso]

Thanks for the detailed incident report and for identifying the retained-table backfill requirement. I reproduced the key schema fact with a fresh OpenCode 1.18.30 store: it creates message, part, and session_message, but not session_v2; the reachable binary also contains no session_v2 string.

We are going ahead with #477 for the main fix rather than superseding it with this PR. The deciding case is downgrade: after a store has been used by OpenCode 2 and then by OpenCode 1 again, session_v2 remains while the live host resumes writing message/part. Making session_v2 win detection globally classifies that store as v2, rejects the active v1 readers (compaction marker writer, dreamer history, migrate, migrate-session), and makes schema-selected diagnostics read frozen v2 rows. #477 keeps mixed stores conservative at detection time and widens only an explicitly requested v2 assertion, so both the migrated and the downgraded shapes pass. It is on master as of 2c034c3.

Your D2 observation is useful and we will carry it. #477 does not currently throw in the backfill because its detector still returns v1 for the mixed store, but gating that job on the presence of the message/part tables is the more accurate contract than a host label. We will land that as a separate follow-up with credit to this PR.

One repository issue at the current head: bun.lock is not restored to master byte-for-byte. It still differs by 1,304 additions and 1,304 deletions, starting at line 8 (master is at 0.42.6, the PR head at 0.42.5). We will not carry that lockfile change.

Closing this PR in favour of #477; #489 stays open as the tracking point for the D2 follow-up.