hermes-agent/tests/test_conftest_wal_gate.py
teknium1 07e97d2f5d
Some checks are pending
CI / Detect affected areas (push) Waiting to run
CI / Python tests (push) Blocked by required conditions
CI / Python lints (push) Blocked by required conditions
CI / JS & TS checks (push) Blocked by required conditions
CI / Desktop E2E (push) Blocked by required conditions
CI / Docs Site (push) Blocked by required conditions
CI / Deny unrelated histories (push) Blocked by required conditions
CI / Check contributors (push) Blocked by required conditions
CI / Check uv.lock (push) Blocked by required conditions
CI / package-lock.json diff (push) Blocked by required conditions
CI / Lint Docker scripts (push) Blocked by required conditions
CI / Build&Test Docker image (push) Blocked by required conditions
CI / Supply-chain scan (push) Blocked by required conditions
CI / Review label gate (push) Blocked by required conditions
CI / OSV scan (push) Waiting to run
CI / CI review comment (live) (push) Blocked by required conditions
CI / All required checks pass (push) Blocked by required conditions
CI / CI timing report (push) Blocked by required conditions
Deploy Site / deploy-vercel (push) Waiting to run
Deploy Site / deploy-docs (push) Waiting to run
Docker Build, Test, and Publish / build (amd64, type=gha,scope=docker-amd64, type=gha,mode=max,scope=docker-amd64, linux/amd64, ubuntu-latest) (push) Waiting to run
Docker Build, Test, and Publish / build (arm64, type=gha,scope=docker-arm64, type=gha,mode=max,scope=docker-arm64, linux/arm64, ubuntu-24.04-arm) (push) Waiting to run
Docker Build, Test, and Publish / publish (amd64, type=gha,scope=docker-amd64, type=gha,mode=max,scope=docker-amd64, linux/amd64, ubuntu-latest) (push) Blocked by required conditions
Docker Build, Test, and Publish / publish (arm64, type=gha,scope=docker-arm64, type=gha,mode=max,scope=docker-arm64, linux/arm64, ubuntu-24.04-arm) (push) Blocked by required conditions
Docker Build, Test, and Publish / merge (push) Blocked by required conditions
auto-fix lint issues & formatting / Generate eslint --fix patch (push) Waiting to run
auto-fix lint issues & formatting / Apply patch (push) Blocked by required conditions
fix(tests): gate WAL-dependent tests on the linked SQLite's real capability
Two tests fail deterministically on main depending only on which SQLite the
test interpreter links — nothing about the code under test. Both are green in
isolation and red in the suite / on an older library, the worst diagnostic
shape.

Root cause A — WAL is not always WAL. Hermes refuses journal_mode=WAL on
SQLite builds carrying the upstream WAL-reset corruption bug (3.7.0–3.51.2,
excluding backports 3.50.7 / 3.44.6) and falls back to DELETE. On such a
build NO -wal sidecar is ever created, so
test_wal_checkpoint_truncates_wal_file asserts on a file that cannot exist.
Invisible locally when the repo .venv and the Hermes managed runtime link
different versions (observed: .venv 3.50.4 → DELETE, runtime 3.53.1 → WAL),
so the same test passes for one interpreter and fails for the other.

  - tests/conftest.py: add a `requires_wal` marker plus a
    pytest_collection_modifyitems hook that skips such tests when the linked
    library will fall back to DELETE. The skip reason names the actual
    version so it is diagnosable rather than mysterious.
  - pyproject.toml: register the marker.
  - test_kanban_db_repair.py: mark the -wal-sidecar test.

Root cause B — process-global warn-once dedup. The WAL-fallback warning is
emitted at most once per (process, db_label). Any earlier test in
test_kanban_db.py that opens a kanban.db consumes that one-shot, so
test_connect_falls_back_to_delete_on_locking_protocol sees zero warnings and
fails — but only as part of the file, never alone.

  - test_kanban_db.py: clear both dedup sets in the test that asserts on the
    warning, with a comment explaining the isolation trap.

The gate deliberately does NOT import hermes_state. That module computes
DEFAULT_DB_PATH from get_hermes_home() at import time, so importing it during
collection — before the per-test _isolate_hermes_home fixture redirects
HERMES_HOME — permanently caches the developer's REAL ~/.hermes/state.db for
the whole session. The first version of this change did exactly that and made
tests read a live 31,881-session production database (test_console_engine
asserted "Total sessions: 2" and got 31881). The version predicate is
duplicated instead, and tests/test_conftest_wal_gate.py pins the two
implementations in agreement across every documented upstream boundary plus
guards against the import coming back.

Verified: on SQLite 3.50.4 the sidecar test SKIPS naming the version; on
3.53.1 it RUNS and passes, so coverage is not lost where WAL works. Clean
main fails exactly these 2 tests under
`scripts/run_tests.sh tests/hermes_cli/ tests/test_hermes_state.py`
(9926 passed, 2 failed); with this change the same scope is green.

Tests: 726 passed across the two kanban files, test_hermes_state.py, and the
new gate tests.
2026-07-25 07:17:52 -07:00

77 lines
2.9 KiB
Python

"""The conftest WAL gate must agree with hermes_state, and must not import it.
``tests/conftest.py::_wal_is_usable`` duplicates the SQLite WAL-reset version
predicate instead of importing ``hermes_state``. That is deliberate: importing
``hermes_state`` during collection caches ``DEFAULT_DB_PATH`` from the real
``~/.hermes`` before the per-test ``HERMES_HOME`` redirect, which makes tests
read the developer's live production database.
Duplication needs a guard, so these tests pin the two implementations in
agreement across the documented upstream boundaries.
"""
import sqlite3
import pytest
from hermes_state import is_sqlite_wal_reset_vulnerable
from tests.conftest import _wal_is_usable
@pytest.mark.parametrize(
"version_info",
[
(3, 6, 23), # pre-WAL
(3, 7, 0), # first WAL release — vulnerable
(3, 44, 5), # below the 3.44 backport
(3, 44, 6), # 3.44 backport — fixed
(3, 45, 0), # next minor, back to vulnerable
(3, 50, 4), # the version that exposed this (repo .venv)
(3, 50, 6), # below the 3.50 backport
(3, 50, 7), # 3.50 backport — fixed
(3, 51, 2), # last vulnerable
(3, 51, 3), # fixed upstream
(3, 53, 1), # the managed runtime
],
)
def test_conftest_gate_agrees_with_hermes_state(version_info, monkeypatch):
"""``_wai_is_usable`` must be the exact inverse of the canonical predicate."""
monkeypatch.setattr(sqlite3, "sqlite_version_info", version_info)
assert _wal_is_usable() is not is_sqlite_wal_reset_vulnerable(version_info), (
f"conftest gate and hermes_state disagree for SQLite {version_info}"
)
def test_conftest_does_not_import_hermes_state_at_collection():
"""The gate must stay import-free of hermes_state.
Importing it during collection caches DEFAULT_DB_PATH from the real
~/.hermes, so tests read live production sessions instead of a tempdir.
Reading the source is not an option here (banned), so assert on behavior:
the gate must work with ``hermes_state`` absent from ``sys.modules`` and
blocked from being imported.
"""
import builtins
import sys
real_import = builtins.__import__
blocked: list[str] = []
def guard(name, *args, **kwargs):
if name == "hermes_state" or name.startswith("hermes_state."):
blocked.append(name)
raise AssertionError(
"conftest._wal_is_usable imported hermes_state — this caches "
"DEFAULT_DB_PATH from the real ~/.hermes during collection"
)
return real_import(name, *args, **kwargs)
saved = sys.modules.pop("hermes_state", None)
builtins.__import__ = guard
try:
_wal_is_usable() # must not raise
finally:
builtins.__import__ = real_import
if saved is not None:
sys.modules["hermes_state"] = saved
assert not blocked