Skip to content

fix(web): invalidate thread snapshot caches predating migration 044 - #23

Merged
asfires merged 1 commit into
mainfrom
t3code/invalidate-stale-thread-cache
Aug 12, 2026
Merged

asfires merged 1 commit into
mainfrom
t3code/invalidate-stale-thread-cache

Conversation

@asfires

@asfires asfires commented Aug 12, 2026

Copy link
Copy Markdown
Owner

Follow-up to #22: the migration deletes orphaned retracted messages directly in sqlite, which emits no orchestration events — so warm IndexedDB thread caches (which resume via afterSequence) keep rendering the deleted ghost messages forever, surviving even hard reloads.

Fix follows the cache's established invalidation pattern (see the v2–v4 comment history): bump the stored-record schemaVersion literal so pre-044 records fail decode and clients cold-load clean snapshots. Also documents the rule that any out-of-band row surgery needs a bump here.

Web typecheck clean; storage tests pass. No new unit test for the decode-invalidation path itself — the workspace has no fake-IndexedDB driver and adding one for this is out of scope; the invalidation mechanism is the same one v3 and v4 already rely on.

Migration 044 deleted orphaned retracted messages directly in sqlite, which emits no orchestration events - warm IndexedDB thread caches resume via afterSequence and would render the deleted ghost messages forever, surviving hard reloads.

Bump the stored thread snapshot schema version so pre-044 cache records fail decode and clients refetch clean snapshots.

Model: Claude Fable 5

Harness: Claude Code
@asfires
asfires merged commit e5ecfc2 into main Aug 12, 2026
6 of 12 checks passed
@asfires
asfires deleted the t3code/invalidate-stale-thread-cache branch August 12, 2026 21:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant