caya8205-2
5ffaed6e45
#88734 made SessionStore._db follow the ambient HERMES_HOME so a multiplexed profile's rows reach its own state.db. That is correct for the inbound message path, which installs the scope via _profile_runtime_scope. Nothing else does. _session_expiry_watcher (gateway/run.py) walks the single process-wide _entries dict — every profile's keys — and finalizes expired sessions with no scope installed, so _db resolved the ROOT store for rows that live under profiles/<name>/state.db. The scoped inbound path and the unscoped background path then maintained two copies of the same logical session whose end_reason drifted apart independently. Once they disagreed, the #54878 stale-routing guard read one copy while the routing index pointed at the other, and a live conversation was dropped and recreated — silently, since that branch only sets was_auto_reset when a reset policy also fired. Field evidence from a live two-profile install: session 20260814_234313 was end_reason=None in the root store but agent_close in the profile store, while 20260822_225807 was inverted. Both directions, which rules out a single mis-scoped writer. The owning profile is already encoded in the session key, so derive the store from it: _profile_home_for_key / _db_for_key, plus _db_for_session_id for the entry points addressed by session id. 40 self._db uses across 14 methods now resolve that way. No signature changed and no existing test was modified. _profile_home_for_key returns None when multiplexing is off, when the key carries the legacy agent:main namespace, or when the profile has no live directory, so single-profile installs resolve exactly where they always did. The explicit-path branch still goes through SessionDB.__init__ -> _ensure_test_isolation, keeping the live-DB guard over per-profile paths. Part of #66887. The routing-index half — _routing_scope() and the sessions.json mirror still pinned to one frozen sessions_dir while the handle moves — is left for a follow-up rather than mixed in here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor email → GitHub login mappings
This directory replaces appending entries to AUTHOR_MAP in
scripts/release.py. The old dict caused constant merge conflicts when
several salvage PRs landed at once — every PR edited the same lines of the
same file. Here, each mapping is its own file, and file additions never
conflict.
Adding a mapping
One file per commit-author email, under emails/:
python3 scripts/add_contributor.py <email> <github-login>
# or by hand:
echo "<github-login>" > contributors/emails/<email>
- File name = the exact commit-author email (as shown by
git log --format='%ae'). - File content = the GitHub login on the first non-comment line.
Lines starting with
#are comments (use them for the PR reference).
Example — contributors/emails/jane.doe@example.com:
janedoe
# PR #12345 salvage (gateway: fix session key routing)
Rules
- Do NOT add new entries to
AUTHOR_MAPinscripts/release.py. That dict is frozen legacy data; the release tooling merges it with this directory (directory entries win on duplicates). - GitHub noreply emails (
<id>+<login>@users.noreply.github.comand<login>@users.noreply.github.com) auto-resolve — no file needed. - The
Contributor Attribution CheckCI job fails a PR whose commits carry an unmapped email; the failure message prints the exact command to run.