COG-5975 fix(cache): unique constraint + upsert for cache_session_context so retried writes can't poison a session

[Vasilije1990]

Description

Fixes #4226 — cache_session_context had no uniqueness on (user_id, session_id, entry_id) (unlike cache_qa_entries, which has uq_cache_qa_entry). The session-context write path is update-then-create across two transactions, so an ordinary client retry after a timeout — or two concurrent writers — inserted a duplicate row. Once duplicates existed, scalar_one_or_none() in SqlCacheAdapter.update_session_context_entry raised on every subsequent write for that session: a permanent 503 recoverable only by manual row deletion (the reporter hit 77 copies of one bookkeeping entry and ~36 failed writes/hour for 6.5 hours).

All four parts of the fix suggested in the issue:

• Unique index uq_cache_session_context_entry on (user_id, session_id, entry_id) — declared as a unique Index rather than a UniqueConstraint so tables created before it existed can be upgraded in place.
• Upsert on create — create_session_context_entry now uses ON CONFLICT DO UPDATE (Postgres + SQLite dialects, same pattern as set_value), so a retried write replaces the payload in place. Id-less entries keep their synthetic UUID and are unaffected.
• In-place migration — _ensure_initialized collapses each duplicate group to its newest row, then runs CREATE UNIQUE INDEX IF NOT EXISTS. Migration failure is non-fatal: the adapter logs a warning and falls back to plain inserts so ON CONFLICT can never error against a missing index.
• Self-healing update — update_session_context_entry fetches all rows for the key ordered by seq, merges into the newest, and prunes older duplicates in the same transaction, so even an un-migrated database recovers on the next write instead of 503ing forever.

The Redis and FS adapters don't share the crash (they update the first list match), so this fix is scoped to the SQL adapter. Follow-up noted in COG-5975: their create_session_context_entry still appends duplicates on retried creates (no crash, but duplicated context) — the adapter-parametrized contract tests from #4129 would be the natural home for cross-adapter idempotency coverage.

Testing

New regression tests in test_sql_adapter_crud.py (sqlite+aiosqlite):

• retried create with the same entry id yields exactly one row with the retried payload
• with legacy duplicates simulated (index dropped, rows stacked), update succeeds, merges into the newest row, and exactly one row remains
• a legacy database is deduped (newest kept per key) and re-indexed on next adapter startup, after which upserts work

pytest cognee/tests/unit/infrastructure/databases/cache/ — 139 passed; cognee/tests/unit/infrastructure/session/ — 181 passed. Ruff lint + format clean.

Related

• Linear: COG-5975
• Introduced in feat(cache): implement session-context CRUD on SqlCacheAdapter (sqlite/postgres) #3072 (table added without a uniqueness guarantee on the update key)
• Same defect class as [Bug]: Batch add() with byte-identical files crashes: UNIQUE constraint failed: data.id (concurrent per-item ingestion races on content-derived data_id) #4029 / fix(ingestion): merge detached data points before linking on concurrent add (#4029) #4034; contract-test home Add adapter-parametrized contract tests for CacheDBInterface (empty-collection and last_n edge cases) #4129

🤖 Generated with Claude Code

[dexters1]

@Vasilije1990 added a PR with the fix here:

#4232

Fix should be handled with an alembic migration of the relational DB

That also resolves the issue for existing users who had it