A session that lived through OpenCode 2's V1 import has a row in both
`session` and `session_v2`, and neither is complete. #22391 resolved the
pair by ranking whole rows on one number — total token count, ties to
`session_v2` — which let that number decide everything else on the row.
Three consequences, each reproduced against that PR's own fixtures:
- A recorded cost could be zeroed. `session_v2` wins on tokens while
carrying `cost = 0`, and row parsing maps a zero cost to `null`, so a
legacy row's $12.50 disappeared. Cost is re-derived by the same lossy
reduce as the tokens, but only the tokens were guarded.
- The token comparison decided metadata. A legacy row with more tokens
supplied a stale pre-migration directory, and a legacy row with a NULL
model erased the model `session_v2` had — 23 of 234 shared ids on a
real migrated database have a model only on the v2 side.
- Winner-takes-all is per row, so a legacy row holding the input tokens
and a v2 row holding the cache reads reported one of them as zero.
Metadata now comes from the generation OpenCode still writes, with older
generations filling only its NULLs; usage columns take a per-column MAX.
Both rows aggregate the same assistant messages, and the import can only
drop messages, never invent them, so each column's MAX is a tighter lower
bound on the truth than either row and can never exceed it.
The relation stays exactly one row per id — the highest-priority
generation holding it — every column stays `columnExists`-guarded with a
SQL fallback, and a database with a single session table builds the same
SQL it did before.
Cache schema version 4 -> 5 so existing caches rescan.
* fix(opencode-usage): read OpenCode 2 session_v2 token totals
OpenCode 2 copies every v1 `session` row into a new `session_v2` table and
then writes only there, so every OpenCode 2 session was invisible to the
usage scanner, which only knew `session`. Reading both tables unfiltered
would double-count the migrated rows, so the scan now builds one
deduplicated session relation where `session_v2` owns any id it shares with
the legacy table, and joins the message-level fallbacks against it too.
Bumps the usage cache schema version so existing caches rescan.
Measured against the real local opencode.db (OpenCode v2.0.12, 234 legacy
`session` rows / 252 `session_v2` rows, 18 of them v2-only):
migrated db before: 206 sessions, 367,419,745 tokens, $79.4704
after: 219 sessions, 374,305,364 tokens, $79.4817
fresh v2 db before: 0 sessions, 0 tokens, $0
(legacy table after: 219 sessions, 374,305,364 tokens, $79.4817
emptied)
Fixes#15841
* fix(opencode-usage): resolve a migrated session to its fuller row
Review found two ways the fixed `session_v2`-wins precedence loses usage.
A `session_v2` without the token columns scores 0 through the source's
fallback literals, but still excluded the legacy row for every shared id, so
a token-bearing legacy `session` paired with a token-less `session_v2`
returned nothing at all — worse than before this branch. And upstream's
importer recomputes v2 totals from decoded messages, so a session whose
messages fail to decode lands *below* its frozen legacy copy, which the
"legacy is frozen, v2 is newer" rationale did not account for.
Both collapse into one rule: per id, the row with the greater token total
wins, and a tie goes to the higher-priority table. A faithful migration is a
tie, so it still resolves to `session_v2`; a v2 row that lost data no longer
erases the legacy record. This also makes `hasSessionUsageColumns`'s `some`
correct rather than merely lenient — a table without the columns can never
outrank a sibling that has them.
Measured on the real local opencode.db: zero shared ids have a legacy row
that beats its `session_v2` counterpart, so the rule is a no-op on healthy
data and only engages on the degraded shapes above.
Both new tests fail on the previous commit and pass here.
Neil