Files
ratatoskr/persistent-memory.d/2026-06-18-latent-sqlite-thread-safety-bug-in-the-affect.md
T
vh ff1f9ca1e8 memory: /snapshot — #368 silo test passed; two-tier migration; stores scrubbed
- #368 (user,character) memory silo test DONE + PASSED live (WT b127):
  write-side conjunctive {end_user,agent_self} scoping + read-side cross-
  character isolation both proven end-to-end; betty (throwaway) deleted,
  Sindra intact. Full record in persistent-memory.d/2026-07-18-368-silo-
  test-passed.md. Retired the stale "silo test in progress" in-flight blocks.
- Two-tier migration: split 152 over-threshold dated entries into
  persistent-memory.d/ detail files, leaving one-line pointers in the index
  (startup load ~196KB -> ~53KB; bodies now load on demand).
- Tier-3 stores scrubbed clean (memory 0 / affect 0, provider restarted
  empty); persistent-memory + detail file updated to reflect the scrub.
2026-07-17 21:39:18 -07:00

2 lines
712 B
Markdown

`[2026-06-18]` **Latent SQLite thread-safety bug in the affect store, surfaced ONLY by the new HTTP read route.** `open_affect_store` created the connection without `check_same_thread=False`; the bifrost emit path never tripped it (uvicorn's loop ran on the connection's creating thread), but the `TestClient`-driven read route runs handlers off a worker thread → `sqlite3.ProgrammingError`. Fix: `check_same_thread=False` (safe — the event loop serializes access) + explicit `PRAGMA busy_timeout=5000` (don't rely on sqlite3's `timeout=5.0` default). **Lesson: a sqlite-backed ASGI app needs `check_same_thread=False`; the HTTP-layer test exposed what the direct-store-method tests structurally couldn't.**