fix(gateway): persist session hygiene compression-failure cooldown to state DB (#74136)

[webtecnica]

Problem

The session hygiene compression path tracked its per-session failure cooldown in an in-memory dict (_hygiene_compression_failure_cooldowns) on the gateway process. When the gateway restarts, that dict is lost, so the same failing compression is immediately re-triggered on the next message - wedging session storage.

The user-visible symptom: after a compression failure (timeout, API error, abort), every message across all sessions gets the "session storage could not be written" error. Restarting the gateway does not recover - it clears the in-memory cooldown and the cycle repeats.

Root Cause

The state DB already has a persistent column sessions.compression_failure_cooldown_until and full read/write/clear methods (record_compression_failure_cooldown / get_compression_failure_cooldown / clear_compression_failure_cooldown in hermes_state.py). The in-conversation compression path (agent/context_compressor.py) already uses these persistent methods correctly. But the session hygiene path in gateway/run.py used its own in-memory dict instead - the two paths disagreed on durability.

Fix

1. Cooldown check (line ~13836): Replace the in-memory dict lookup with await session_db.get_compression_failure_cooldown(session_id), consistent with the in-conversation path.
2. Timeout cooldown write (line ~14020): Replace in-memory dict write with await session_db.record_compression_failure_cooldown(...).
3. Abort cooldown write (line ~14186): Same replacement, with proper error text redaction before persistence.
4. Tests (6 assertions across 4 test functions): Updated to assert against session_db._db mocks instead of the removed in-memory dict.

Fixes #74136

[alt-glitch]

This was generated by AI during triage.

Duplicate of #74251 — both persist the session-hygiene compression-failure cooldown through SessionDB so a gateway restart cannot immediately re-trigger the failing path.

[teknium1]

Thanks for targeting the persistent cooldown mismatch. The premise remains valid on current main: hygiene still uses the process-local map at gateway/run.py:16041-16054, with writes at gateway/run.py:16225-16227 and gateway/run.py:16390-16393.

Problems

• The updated tests do not provide the async facade the production code awaits. Production creates AsyncSessionDB(SessionDB()) at gateway/run.py:5782-5785; its callable forwarding is awaitable at hermes_state.py:8555-8569. The changed hygiene fixtures retain SimpleNamespace(_db=MagicMock()) (for example tests/gateway/test_session_hygiene.py:505), so the new outer-facade lookup/write raises AttributeError and is swallowed. The raw _db mock recorder is therefore not called.
• The central restart guarantee lacks a SessionDB-backed regression.

Suggested changes

• Wrap the test mock in AsyncSessionDB, or expose explicit outer AsyncMock lookup/record methods; configure inactive lookup values where compression should proceed.
• Add a regression that persists a cooldown, constructs a fresh gateway DB facade over the same state DB, and verifies hygiene skips compression.

Automated hermes-sweeper review.

[teknium1]

Closing as a duplicate of #74251, which was submitted earlier with the same fix (swap the in-memory _hygiene_compression_failure_cooldowns dict for the DB-backed cooldown methods) and which we're salvaging for #74136 — adding a real AsyncSessionDB-backed restart regression test on top, since the existing mocks assert nothing against the awaited production path.

Your test-update intent will be folded into that salvage. Thanks — premise fully confirmed on main.