fix(dashboard): derive the stale-schema read probe from SCHEMA_SQL
After `hermes update`, the desktop sidebar showed "No sessions yet" until the user's first message. #72424 added sessions.last_activity_at, which list_sessions_rich now selects — but column adds only land through _reconcile_columns() in the writable _init_schema, and read-only opens skip that by design. Every sidebar read path opens state.db read-only, so each poll raised "no such column: s.last_activity_at" until the first prompt's lazy session-row persist forced a writable open and reconciled. A heal for exactly this class already existed (_open_session_db_for_profile probes the read-only handle and does a one-time writable reopen on staleness), but its probe was a hand-written four-column list that never learned last_activity_at — it went stale three days after shipping. And the batched sidebar route (/api/profiles/sessions/sidebar) bypassed the helper entirely, swallowing per-profile failures into an errors array the desktop never surfaces, so the incident produced an empty sidebar with clean logs. The fix removes the maintenance burden instead of paying it once more: - hermes_state_schema.schema_read_probe_statements() derives one `SELECT <every declared column> FROM <table> LIMIT 0` per table from SCHEMA_SQL via the existing _parse_schema_columns() — the same source of truth the writable reconciler diffs against, so any future ADD COLUMN is probed with no list to update. Column references are table-qualified: an unqualified double-quoted identifier that fails to resolve silently degrades to a string literal (SQLite's double-quoted-string misfeature) and would make the probe pass on exactly the store it exists to catch. - web_server splits the heal into a path-level _open_session_db_at_path (semantics unchanged) so the cross-profile session routes can share it; both profiles.py loops and _count_status_active_sessions (the remaining raw read-only sibling) now open through it. The heal stays a helper rather than a SessionDB classmethod on purpose: escalation-to-writable must remain an explicit caller decision — update_cmd.py opens read-only mid-update and must never write. - Exhaustion guard: if the writable heal SUCCEEDS and the re-probe still fails (a schema problem ADD COLUMN cannot express), the store is marked exhausted — warn once, skip the probe, serve reads probe-less — instead of re-running the full writable init on every poll against a possibly live DB. A FAILED writable open (transient lock) is deliberately not recorded, so the next poll retries the heal. - The per-profile swallow sites in profiles.py now also log a deduplicated warning, so a persistent read failure is loud in errors.log even though the response errors array stays invisible to the sidebar. Tests: probe/SCHEMA_SQL coverage invariants (tests/test_schema_read_probe.py), last_activity_at added to the /api/sessions heal parametrize, a sidebar-route heal test reproducing the shipped symptom (errors == [] and the session returned against a store missing the column), and an exhaustion test pinning exactly one writable open. The sidebar and last_activity_at tests fail on main.
This commit is contained in:
@@ -32,6 +32,53 @@ from hermes_state_common import (
|
||||
# keep that logger identity so log filtering/capture behavior is unchanged.
|
||||
logger = logging.getLogger("hermes_state")
|
||||
|
||||
# Cache for schema_read_probe_statements() — parsing SCHEMA_SQL spins up an
|
||||
# in-memory SQLite database, so derive the statements once per process.
|
||||
_READ_PROBE_STATEMENTS: Optional[tuple] = None
|
||||
|
||||
|
||||
def schema_read_probe_statements() -> tuple:
|
||||
"""SELECT statements that fail iff a live store is behind SCHEMA_SQL.
|
||||
|
||||
Read-only opens skip ``_reconcile_columns()`` by design (no DDL against
|
||||
another profile's live DB), so a store created before a schema addition
|
||||
keeps 500ing on read paths until something opens it writable. Callers
|
||||
that heal on staleness (see ``_open_session_db_at_path`` in
|
||||
``hermes_cli/web_server.py``) run these probes right after a read-only
|
||||
open: any missing table raises "no such table" and any missing column
|
||||
raises "no such column", both at prepare time.
|
||||
|
||||
Derived from SCHEMA_SQL — the same source of truth the writable
|
||||
reconciler diffs against — so a column added there is covered here
|
||||
automatically. A hand-maintained probe list went stale within days of
|
||||
shipping (it never learned ``sessions.last_activity_at``, so the sidebar
|
||||
served an empty session list after `hermes update` until the user's
|
||||
first message forced a writable open).
|
||||
|
||||
Each statement is ``LIMIT 0``: column resolution happens at prepare
|
||||
time, so the probe reads zero rows. Column references are qualified
|
||||
with the table name — an unqualified double-quoted identifier that
|
||||
fails to resolve silently degrades to a string literal (SQLite's
|
||||
double-quoted-string misfeature), which would make the probe pass on
|
||||
exactly the stale store it exists to catch.
|
||||
"""
|
||||
global _READ_PROBE_STATEMENTS
|
||||
if _READ_PROBE_STATEMENTS is None:
|
||||
tables = SessionSchemaMixin._parse_schema_columns(SCHEMA_SQL)
|
||||
_READ_PROBE_STATEMENTS = tuple(
|
||||
'SELECT {} FROM "{}" LIMIT 0'.format(
|
||||
", ".join(
|
||||
'"{}"."{}"'.format(
|
||||
table.replace('"', '""'), col.replace('"', '""')
|
||||
)
|
||||
for col in cols
|
||||
),
|
||||
table.replace('"', '""'),
|
||||
)
|
||||
for table, cols in sorted(tables.items())
|
||||
)
|
||||
return _READ_PROBE_STATEMENTS
|
||||
|
||||
|
||||
class SessionSchemaMixin:
|
||||
"""See module docstring — mixin for SessionDB (Schema cluster)."""
|
||||
|
||||
Reference in New Issue
Block a user