hermes-admin/hermes-agent
1
0
Fork 0
Code Issues Pull Requests Actions 30 Packages Projects Releases Wiki Activity

test(auth): accept token_bases in the refresh-race pool-store fake; doc the write boundary

Browse Source 
write_credential_pool now takes token_bases, so the in-memory fake standing
in for auth.json in the refresh-race tests must accept it or every persist
in those tests raises TypeError inside the refresh thread. Also carries the
credential-pools doc sentence describing the stale-writer boundary.

Hunks taken verbatim from #120816.
This commit is contained in:
John Paul Soliva
2026-09-24 13:56:52 +05:30
committed by kshitij
parent badd8f56e4
commit dde9f3581d
2 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
tests/agent/test_credential_pool_anthropic_refresh_race.py
View File

@@ -71,7 +71,7 @@ def _fake_pool_store(monkeypatch):
"""
store: Dict[str, list] = {}
def _write(provider, entries, *, removed_ids=None, status_cleared_ids=None):
def _write(provider, entries, *, removed_ids=None, status_cleared_ids=None, token_bases=None):
store[provider] = list(entries)
def _read(provider=None):

2
website/docs/user-guide/features/credential-pools.md
View File

@@ -319,7 +319,7 @@ This means subagents benefit from the same rate-limit resilience as the parent,
The credential pool uses a threading lock for all state mutations (`select()`, `mark_exhausted_and_rotate()`, `try_refresh_current()`, `mark_used()`). This ensures safe concurrent access when the gateway handles multiple chat sessions simultaneously.
Across processes (many subagents, a gateway plus a CLI, cron jobs), OAuth refreshes are serialized through a file lock on `auth.json`. When one shared OAuth grant expires under many concurrent processes, exactly one process performs the refresh; the others detect that the on-disk token no longer matches the one that failed and adopt it instead of rotating the single-use refresh token again. A process that loses the lock race keeps its entry healthy and retries — lock contention is never recorded as a credential failure.
Across processes (many subagents, a gateway plus a CLI, cron jobs), OAuth refreshes are serialized through a file lock on `auth.json`. When one shared OAuth grant expires under many concurrent processes, exactly one process performs the refresh; the others detect that the on-disk token no longer matches the one that failed and adopt it instead of rotating the single-use refresh token again. A process that loses the lock race keeps its entry healthy and retries — lock contention is never recorded as a credential failure. A session or process still holding an older copy of the pool never writes that copy's tokens back over a pair another one rotated since; it keeps the newer pair on disk and adopts it.
## Architecture