avo: suite green; tests+41 fc=True docs=True debt+0
What this does, in plain terms
When people record with Omi, the backend keeps two small pointers in Redis —
"which conversation is currently being built for this user" and "which
calendar meeting this recording belongs to." They are conveniences: if Redis
doesn't have them, the backend falls back to slower paths and everything
still works.
The bug: when Redis ran out of memory (which happened in production), writing
those two pointers crashed the session instead of being skipped. Result: a
user in the middle of a live recording could have their listening session
torn down (supervisor crash, ASGI WebSocket traceback) — for a cache write
the system is designed to live without.
This PR makes both writes best-effort: on Redis capacity errors they are
skipped with a log line instead of raising. If Redis is full, a small number
of conversations lose meeting attribution (falls back to calendar-overlap
matching during processing) and in-progress lookups go to Firestore directly
— degraded, not broken. No user-visible behavior changes when Redis is
healthy.
Merging this stops live recording sessions from dying during Redis
capacity events. It does not fix Redis capacity itself.
Where it came from
Automated root-cause fix from the AVO loop (candidate ec96f19b), selected
from production error telemetry. Human-committer review on this branch.
How it was verified
- New tests fail on the parent commit and pass on this one:
tests/unit/test_redis_pointer_writes_fail_open.py(207 lines) and
tests/unit/test_listen_session_survives_redis_maxmemory.py(732 lines,
full listen-session survival under maxmemory). - Backend suite green locally; formatting clean on all changed files.
- Scorer: suite green; tests +41; no new debt markers.
- Operational contract written up in
backend/docs/operational/redis-pointer-writes-fail-open.md(new).
Size exception
Line-Count-Exception: backend/database/redis_db.py | 1719 -> 1730 | required by an automated root-cause fix; no feature surface added