Fix/google chat bot id cache home - #39486
Conversation
The bot-id cache resolved HERMES_HOME via a raw os.getenv with a Path.home()/.hermes fallback, while the thread-count store and oauth helper use get_hermes_home(). When HERMES_HOME is unset or a context-local profile override is active, the two diverge, so the bot-id cache lands in a different home than the rest of the adapter state. The cache then misses on every restart, triggering redundant members.list calls and leaving self-filtering on the "bot_user_id not yet resolved" fallback. Resolve _bot_id_cache_path() through get_hermes_home() with the same import fallback already used by the thread-count store. Behavior is unchanged when HERMES_HOME is set. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Maps drexux0@gmail.com to its GitHub username so the contributor attribution check passes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Thanks for the focused regression fix. The premise remains present on current main: The proposed replacement in No correctness or design blocker was identified. This is an automated hermes-sweeper review. |
GottZ
left a comment
There was a problem hiding this comment.
This was generated by AI during triage.
Summary
Two open PRs address the same Google Chat bot-ID cache-path bug: both replace the raw HERMES_HOME lookup with profile-aware get_hermes_home() resolution, while #39486 additionally covers the distinct native-Windows default-path divergence.
Related pull requests
- #39486
related— (+95/-3) — preferred: Replaces the raw environment lookup with get_hermes_home(), directly fixing cache divergence for context-local profiles and native Windows; its three regression tests cover explicit HERMES_HOME, context-local override, and the Windows-native default. The scripts/release.py change is contributor attribution and unrelated to runtime behavior. - #52194
duplicate— (+47/-2) — duplicate of #39486: Implements the same adapter change and tests explicit HERMES_HOME plus context-local override, but omits #39486's native-Windows fallback regression case. Despite the keep_open review on #52194, that review itself identifies #39486 as the earlier duplicate with the additional focused Windows coverage, so retaining both does not add a distinct fix.
Duplicates
#39486 and #52194 implement the same get_hermes_home()-based cache-path correction; #52194 is substantially duplicated by the earlier and more complete #39486.
Suggested consolidation
Merge #39486 because it applies the shared root-cause fix and provides the broader regression matrix, including native Windows; close #52194 as a duplicate. This consolidation does not contradict a correctness blocker—the keep_open review on #52194 reported none and specifically noted #39486's additional Windows test.
Complex graph
flowchart LR
classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
classDef best stroke-width:3px,stroke:#b45309
classDef target stroke-width:3px,stroke:#4338ca
subgraph Dup39486 ["PRs duplicating each other"]
P39486["PR #39486 (open)"]
P52194["PR #52194 (open)"]
end
class P39486 open
class P52194 open
class P39486 target
click P39486 "https://github.com/NousResearch/hermes-agent/pull/39486"
click P52194 "https://github.com/NousResearch/hermes-agent/pull/52194"
Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed or no verify verdict yet (state tag in the node label).
Cross-PR triage: Reviewed 2 pull requests and 0 issues in this complex. Each diff was read against this issue; Assessment working set: 10 kB of PR diffs, 6 kB of issue/PR text, 2 kB of discussion (3 comments), 1 verify verdict. verdicts reflect diff content, not PR titles. Part of an automated triage batch.
What?
The Google Chat adapter resolved
HERMES_HOMEtwo different ways: thethread-count store used
get_hermes_home(), but_bot_id_cache_path()used araw
os.getenv("HERMES_HOME", str(Path.home() / ".hermes")). WhenHERMES_HOMEis unset or a context-local profile override is active, the two diverge — so the
bot-id cache lands in a different home than the rest of the adapter's state. The
cache then misses on every gateway restart, triggering redundant
members.listcalls and leaving self-filtering on the "bot_user_id not yet resolved" fallback.
Fix
_bot_id_cache_path()now resolves throughget_hermes_home(), using the sameimport fallback already used by the thread-count store and
oauth.py. Allpersistence paths in the plugin now share a single
HERMES_HOME, and profileoverrides are honored. Behavior is unchanged when
HERMES_HOMEis set.Tests
Added
TestBotIdCachePathAlignment(3 cases: env-set parity, unset-fallbackalignment, context-local override). Verified the new tests fail against the
pre-fix code and pass after the fix.
$ pytest tests/gateway/test_google_chat.py 163 passed