fix(state): avoid config-writer waits in journal-policy checks

[dokterdok]

Avoid unnecessary database waits while settings are saved

While settings are being saved, opening an established Kanban database can wait unnecessarily just to check its journal policy. This bounded SQLite/config fix uses the safely observed mode for an initialized database instead of waiting for the full config loader. Found during #97681 work, it changes no execution ownership and does not make every database-opening or Stop path nonblocking.

Behavior and limits

• Existing WAL stays WAL, with its companion settings and deduplicated vulnerability warning.
• An initialized DELETE database may retain DELETE during contention when strict WAL is not required.
• New, empty, unknown-mode and strict non-WAL cases still require real policy. Configuration-driven transitions are deferred, not guessed.
• Cold imports do not invert the module/config locks, and a successfully acquired config lock is released on every exit.

This does not make all SessionDB opening or read-pool expansion independent of config writes. Those paths also call apply_database_pragmas(), whose separate config load can still wait. That pre-existing boundary is unchanged.

No timeout, retry loop, config key, new SQLite BUSY classification or live journal downgrade is introduced.

Verification

Refreshed by a normal merge onto main b9271bcb34e1. The original two-file patch is byte-for-byte unchanged.

Check	Result
Canonical focused SQLite/config suite on this candidate	79 passed /0 failed, four files, zero retries
Unchanged authored regression on main b9271bcb34e1	Five expected config-lock timeouts, four passes
Same regression on the candidate	9 passed /0 failed; already included in the 79
Scoped Ruff, whitespace and independent reconciliation review	Passed; review bound to tree 134152f492ec4979215765f769ebc60391f686c7

The earlier three independent probes remain historical evidence from the previous refresh; they are not new tests added to these totals. No full-repository, live Stop, platform or release acceptance is claimed. GitHub CI remains a separate gate.

Exact source, command and attribution

Current head: 029ca5a064a0. Two-file comparison against the tested main.

Run with disposable state:

HERMES_TEST_FILE_RETRIES=0 scripts/run_tests.sh -j 2 \
  tests/test_state_config_contention.py \
  tests/hermes_state/test_hermes_state_wal_fallback.py \
  tests/hermes_state/test_journal_mode_config.py \
  tests/hermes_state/test_sqlite_wal_reset_gate.py

The sibling test paths follow main's test-directory reorganization. Coverage retains old rows and journal modes, deferred upgrades, strict initialization, concurrent readers, cold imports and warning behavior. Both changed files remain below 2K lines.

Original published head 22131bb68787 and the previous refresh 43ea3c841fdc remain ancestors. No source history was rewritten. #98073 carries an authored equivalent: land or salvage the behavior once with attribution. #101384 concerns a separate concurrent WAL-transition race; its retry logic is neither imported nor duplicated.

[Enough1122]

AI code review — automated review for reference; please use your judgment.

Summary

Avoids stalling initialized databases on a held config lock: when _CONFIG_LOCK is contended, apply_wal_with_fallback preserves the on-disk journal mode for established databases (with WAL-reset-bug guards) instead of blocking on resolve_journal_mode(); unestablished/require_wal paths still wait for real policy. Also guards against lock-order inversion during partial hermes_cli.config import.

Findings

• Non-blocking — hermes_state_wal.py:11-14: the __spec__._initializing guard prevents using a half-initialized config module's lock — the subprocess test pins the exact inversion scenario. Careful.
• Non-blocking — hermes_state_wal.py:16-28: non-blocking acquire + observed-mode preservation means a config writer's policy change is deferred, not lost — test_deferred_mode_change_is_applied_after_writer_finishes proves the next open applies it. Correct eventual-consistency design.
• Non-blocking — stale-read consideration: while the writer holds the lock, the opener keeps the observed mode even if the pending write changes policy. Bounded (one open) and resolved on the next call. Fine.
• Non-blocking — WAL-reset-vulnerable branch still forces DELETE logging (_log_wal_reset_bug_once) on the fast path. Safety logging preserved under contention. Good.

Verdict

Correct lock-contention design with thorough concurrency tests. No blocking issues.

[dokterdok]

Superseded by the same two-file implementation and regression test in open runtime PR #106742 (commit e06d714). The source and replayed commit have identical file blobs, and that commit remains reachable from #106742 at 485d5f6. Closing this duplicate review entry as incorporated in that open PR—not merged into main or deployed. The source branch and history are retained; if #106742 drops the fix, revisit this closure.