Skip to content

fix(honcho): align peer-card read and write paths#27979

Closed
cyb0rgk1tty wants to merge 1 commit into
NousResearch:mainfrom
cyb0rgk1tty:fix/honcho-peer-card-read-write-alignment
Closed

fix(honcho): align peer-card read and write paths#27979
cyb0rgk1tty wants to merge 1 commit into
NousResearch:mainfrom
cyb0rgk1tty:fix/honcho-peer-card-read-write-alignment

Conversation

@cyb0rgk1tty

Copy link
Copy Markdown

What does this PR do?

Fixes honcho_profile(peer="user") returning an empty card even when Honcho has a populated peer card for the user. Two independent bugs combined to produce the symptom:

Bug 1 — Read path (related to #17124): get_peer_card() calls _fetch_peer_card(observer, target=user), which hits GET /peers/{observer}/card?target={user} — the observer's local card of the user. On self-hosted Honcho v3 this slot is empty unless writes also use it; the peer card lives on the user peer itself (GET /peers/{user}/card).

Fix: when the observer-target slot returns empty and a target exists, fall back to _fetch_peer_card(target) — the target peer's own card.

Bug 2 — Write path (related to #20729): set_peer_card() resolved only the target peer and called user_peer.set_card(card). The read path uses the assistant peer as observer, so writes and reads addressed different Honcho card scopes. honcho_profile(card=[...]) reported success while a subsequent honcho_profile() still returned empty.

Fix: align set_peer_card() with _resolve_observer_target() so it writes to assistant_peer.set_card(card, target=user_peer_id), matching the read side.

Both fixes together ensure reads and writes use the same scope, and the read-side fallback handles existing deployments where cards were written directly to the peer.

Related issues / PRs

Type of change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✅ Tests (adding or improving test coverage)

Changes made

  • plugins/memory/honcho/session.py
    • get_peer_card: add fallback to target peer's own card when observer-target slot is empty
    • set_peer_card: use _resolve_observer_target so write scope matches read scope
  • tests/honcho_plugin/test_session.py
    • test_get_peer_card_falls_back_to_target_peer_own_card: regression test for the read fallback
    • test_set_peer_card_uses_observer_target_in_ai_observe_others_mode: regression test for write alignment

Validation

python -m pytest tests/honcho_plugin/test_session.py -q -o 'addopts='
# 117 passed

python -m pytest tests/honcho_plugin/ -q -o 'addopts='
# 269 passed

ruff check plugins/memory/honcho/session.py tests/honcho_plugin/test_session.py
# All checks passed

Checklist

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits
  • I searched for existing PRs and referenced them above
  • My PR contains only changes related to this fix
  • I've added tests for my changes
  • I've run pytest tests/honcho_plugin and all tests pass
  • I've run ruff check and all checks pass

honcho_profile(peer="user") returned an empty card even when Honcho
held a populated peer card for the user. Two independent bugs combined
to produce the symptom:

1. Read path: get_peer_card() called _fetch_peer_card(observer, target=user),
   which hits GET /peers/{observer}/card?target={user} — the observer's local
   card of the user. On self-hosted Honcho v3 this slot is empty unless writes
   also use it. The peer card lives on the user peer itself
   (GET /peers/{user}/card). Add a fallback: when the observer-target slot is
   empty and a target exists, retry against the target peer's own card.

2. Write path: set_peer_card() resolved only the target peer and called
   user_peer.set_card(card). The read path uses the assistant peer as
   observer, so writes and reads addressed different Honcho card scopes.
   Align set_peer_card() with _resolve_observer_target() so writes go to
   assistant_peer.set_card(card, target=user_peer_id), matching the read.

Both paths now use the same observer/target resolution, and the read
path additionally falls back to the target's own card for compatibility
with deployments where cards were written directly to the peer.

Closes: related to NousResearch#13375, NousResearch#17124, NousResearch#20729
@alt-glitch alt-glitch added type/bug Something isn't working P3 Low — cosmetic, nice to have comp/plugins Plugin system and bundled plugins tool/memory Memory tool and memory providers duplicate This issue or pull request already exists labels May 18, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Duplicate of #17186 (and #20729, #23022). All fix the same Honcho peer-card read/write path misalignment — set_peer_card() writes to a different scope than get_peer_card() reads. This PR combines both read-side fallback (#17124) and write-side alignment (#20729) which is a superset but covers identical ground.

@teknium1

Copy link
Copy Markdown
Contributor

Thanks for the bug fix — this has already landed on current main, so I’m closing this duplicate as implemented.

Automated hermes-sweeper review evidence:

  • plugins/memory/honcho/session.py:1089 now reads the observer-target card first and falls back to self._fetch_peer_card(target_peer_id) when that slot is empty.
  • plugins/memory/honcho/session.py:1244 now resolves observer/target with _resolve_observer_target() and writes with peer_obj.set_card(card, target=target_peer_id) when a target exists.
  • tests/honcho_plugin/test_session.py:217 and tests/honcho_plugin/test_session.py:237 include regression tests for the read fallback and write alignment.
  • Landed as 1800a1c7963d98962416fa0d3999789e24f9d37a (fix(honcho): align peer-card read and write paths), which is contained in main/origin/main and release tag v2026.5.28.

This matches the duplicate note from @alt-glitch that the PR covered the same Honcho peer-card read/write path misalignment.

@teknium1 teknium1 closed this Jun 13, 2026
@teknium1 teknium1 added the sweeper:implemented-on-main Sweeper: behavior already present on current main label Jun 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/plugins Plugin system and bundled plugins duplicate This issue or pull request already exists P3 Low — cosmetic, nice to have sweeper:implemented-on-main Sweeper: behavior already present on current main tool/memory Memory tool and memory providers type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants