Severity: critical
File: backend/main.py:5940 (exception swallow), same mark_absent consequence as the Cline finding
Audited through: c92dfce
Suggested labels: bug, bug-audit (I don't have permission to apply labels on this repo — please add)
Defect
The entire per-Hermes-DB session-building loop (main.py:5827-5939, including SQL reads that can hit WAL lock contention while Hermes itself is writing) is wrapped in a bare except Exception: pass with no logging.
Why this corrupts data
Same shape and same downstream path as the Cline finding (#222): this feeds into _persist_history_async → history_store.mark_absent, so a single failed scan of one Hermes profile DB silently flips source_present=0 for every session in that profile, even though nothing on disk changed.
Scenario
A Hermes worker is mid-write to its SQLite DB when TokenTelemetry's scan runs; the resulting lock/read error is swallowed, and every session previously tracked for that profile is marked "pruned" in history.db in one scan.
Suggested direction
Log the exception; don't let a failed-to-scan profile's absence from this cycle's session list mark its previously-known sessions as gone from disk.
Full audit report: docs/audits/2026-08-01-bug-audit.md (PR #220)
Severity: critical
File:
backend/main.py:5940(exception swallow), samemark_absentconsequence as the Cline findingAudited through: c92dfce
Suggested labels: bug, bug-audit (I don't have permission to apply labels on this repo — please add)
Defect
The entire per-Hermes-DB session-building loop (
main.py:5827-5939, including SQL reads that can hit WAL lock contention while Hermes itself is writing) is wrapped in a bareexcept Exception: passwith no logging.Why this corrupts data
Same shape and same downstream path as the Cline finding (#222): this feeds into
_persist_history_async→history_store.mark_absent, so a single failed scan of one Hermes profile DB silently flipssource_present=0for every session in that profile, even though nothing on disk changed.Scenario
A Hermes worker is mid-write to its SQLite DB when TokenTelemetry's scan runs; the resulting lock/read error is swallowed, and every session previously tracked for that profile is marked "pruned" in history.db in one scan.
Suggested direction
Log the exception; don't let a failed-to-scan profile's absence from this cycle's session list mark its previously-known sessions as gone from disk.
Full audit report: docs/audits/2026-08-01-bug-audit.md (PR #220)