fix: retry holographic memory sqlite locks - #40167
Closed
JimGat wants to merge 1 commit into
Closed
Conversation
Increase the holographic memory SQLite busy timeout and retry transient database-is-locked write failures after rolling back any pending transaction. Add coverage for busy_timeout plus fact_store/fact_feedback retry behavior.
alt-glitch
added
type/bug
TheoLong
pushed a commit
to TheoLong/hermes-agent
that referenced
this pull request
Jun 21, 2026
Carry-patch of upstream PR NousResearch#40167 (JimGat). Explicit PRAGMA busy_timeout=60000 + retry-on-locked with rollback for fact_store/fact_feedback writes, so the always-on gateway and a concurrent CLI/cron self-reflect subprocess no longer fast-fail with 'database is locked' under SQLite writer contention. Applied locally ahead of upstream merge; drop on the next hermes update once NousResearch#40167 lands. Diagnosed via the daily-self-reflect cron timeout investigation (fact_store writes from the headless subprocess failing while the gateway held the WAL write lock).
TheoLong
pushed a commit
to TheoLong/hermes-agent
that referenced
this pull request
Jul 4, 2026
Carry-patch of upstream PR NousResearch#40167 (JimGat). Explicit PRAGMA busy_timeout=60000 + retry-on-locked with rollback for fact_store/fact_feedback writes, so the always-on gateway and a concurrent CLI/cron self-reflect subprocess no longer fast-fail with 'database is locked' under SQLite writer contention. Applied locally ahead of upstream merge; drop on the next hermes update once NousResearch#40167 lands. Diagnosed via the daily-self-reflect cron timeout investigation (fact_store writes from the headless subprocess failing while the gateway held the WAL write lock). (cherry picked from commit 9d8f60c)
TheoLong
pushed a commit
to TheoLong/hermes-agent
that referenced
this pull request
Jul 6, 2026
Carry-patch of upstream PR NousResearch#40167 (JimGat). Explicit PRAGMA busy_timeout=60000 + retry-on-locked with rollback for fact_store/fact_feedback writes, so the always-on gateway and a concurrent CLI/cron self-reflect subprocess no longer fast-fail with 'database is locked' under SQLite writer contention. Applied locally ahead of upstream merge; drop on the next hermes update once NousResearch#40167 lands. Diagnosed via the daily-self-reflect cron timeout investigation (fact_store writes from the headless subprocess failing while the gateway held the WAL write lock). (cherry picked from commit 9d8f60c)
Contributor
|
Closing as superseded: the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
PRAGMA busy_timeoutdatabase is lockedfailures infact_storeandfact_feedbackafter a safe rollbackWhy
On a live Hermes install using holographic memory, both the always-on gateway and an active CLI session can touch the same SQLite database. Under writer contention,
fact_store/fact_feedbackwrites can fail quickly withdatabase is lockedeven though the DB is healthy and WAL mode is enabled.This change makes those write paths tolerate short-lived SQLite writer contention instead of surfacing a transient tool error to the model/user.
Test Plan
venv/bin/python -m py_compile plugins/memory/holographic/store.py plugins/memory/holographic/__init__.py tests/agent/test_memory_provider.pyvenv/bin/python -m pytest tests/agent/test_memory_provider.py -q -o 'addopts=' --tb=shortvenv/bin/python -m pytest tests -k 'holographic or memory' -q -o 'addopts=' --tb=short