hermes - 💡(How to fix) Fix feat(plugins): expose chat_id (and sender metadata) on pre_llm_call / post_llm_call hooks [1 participants]

TL;DR

Plugins that need to push outbound messages (replies, approval cards, scheduled deliveries) currently can't, because the inbound MessageEvent's chat_id is never propagated to the hook layer. pre_llm_call only carries sender_id + platform; post_llm_call doesn't even carry those.

For Lark / Feishu specifically this is fatal: gateway/platforms/feishu.py adapter send() hard-codes receive_id_type=chat_id, so an outbound call built from a plugin's stored sender_id (a tenant user_id) gets rejected by Lark with [230001] invalid receive_id.

Concrete impact

I'm building PAID — a Hermes plugin that runs an approval workflow over inbound IM messages. The flow is:

1. Junior DMs the bot.
2. PAID's pre_llm_call classifies the message; if the action is request, PAID stores a pending approval and DMs an approval card to the owner (separate Lark session).
3. Owner runs /paid-approve <id> in their own session.
4. PAID needs to push the approved final answer back to the junior.

Step 4 is where it falls apart: PAID has the junior's sender_id (4ed67983 in our test) but no chat_id, and the feishu adapter's send() only accepts chat_ids. The whole approval loop is broken without it.

We've shipped a workaround in PAID v0.5: detect the receive_id format and bypass the adapter with a direct lark_oapi call using the inferred receive_id_type. It works, but it reaches into the adapter's _client (private attr) and depends on lark-oapi import paths. An upstream fix would let plugins stay above that abstraction.

Proposal

1. Add chat_id to pre_llm_call kwargs (highest impact, smallest change)

Around run_agent.py:10656 (v0.12.0):

_pre_results = _invoke_hook(
    "pre_llm_call",
    session_id=self.session_id,
    user_message=original_user_message,
    conversation_history=list(messages),
    is_first_turn=(not bool(conversation_history)),
    model=self.model,
    platform=getattr(self, "platform", None) or "",
    sender_id=getattr(self, "_user_id", None) or "",
    chat_id=getattr(self, "_chat_id", None) or "",   # ← new
)

Plugins can then store (sender_id → chat_id) mappings on first inbound and use chat_id directly for outbound, eliminating the hard-coded-chat_id constraint downstream.

2. Pass platform + sender_id to post_llm_call too

Today only session_id / assistant_response / model make it through. Plugins doing per-counterparty post-checks (PAID's Layer 4 PII / cross-cp leakage scan, for instance) currently have to maintain their own session_id→sender map at pre-time — workable but redundant when the gateway already knows.

3. (Bonus, optional) chat_type, msg_id, sender_display_name

Useful but not blocking. chat_type (private/group) lets plugins gate behaviour for group messages; msg_id enables threaded reply UX; sender_display_name saves a contact-API roundtrip.

Why this is well-scoped

• Backward compatible: callbacks that don't accept the new kwarg keep working (Python **kwargs already in use).
• No behaviour change unless a plugin actively reads the new fields.
• Already implemented inside MessageEvent.source — this is just a propagation gap.

Happy to send a PR if you'd accept this shape. Want to confirm the kwarg names and which subset (just chat_id, vs. the full bundle in §3) before I write it.

Filed against v0.12.0. Cross-reference: PAID plugin's workaround lives at https://github.com/jimmyag2026-prog/paid-plugin/blob/main/paid/hermes_io.py in _send_lark_direct and _detect_lark_receive_id_type.