Cairn

Feishu receive_id_type inferred from ID prefix

NousResearch/hermes-agent · cluster 7685 · gateway

Data as of

4 open items. Fix attempted, not merged.

The short answer

1open issue
3open PRs
5items grouped
Known?
Yes. 5 related items grouped here, 1 issue already closed.
Fix event
No fix has been merged to main. see the attempts below.
Tracker
The maintainers' tracker marks this unresolved. That is separate from the fix event.
Still open
1 issue and 3 PRs.

Multiple issues and fixes addressing a bug where the Feishu adapter hardcodes receive_id_type as 'chat_id', causing delivery failures when targeting open_id (ou_) recipients. The proposed fix infers receive_id_type dynamically from the ID prefix.

Open issues1

  • Issue#7685fix(feishu): _send_raw_message hardcodes receive_id_type="chat_id", breaks delivery to open_id (ou_) targets

Open PRs3

  • PR#7694fix(feishu): infer receive_id_type from ID prefix in _send_raw_message
  • PR#7769fix(feishu): infer receive_id_type from chat_id prefix
  • PR#113617fix(feishu): infer union_id receive type from on_ prefix
Closed issues · 1
  • Closed#9980Feishu: send to user open_id fails with [230001] invalid receive_id
How this cluster was grouped
  • Link evidence (partly structural links): some members are connected by structural evidence (shared changed files, or a closing/superseded reference); the rest are joined by an automated relevance judgement over their text.
  • Members outside that structural core may belong to a different underlying problem.
  • Pairwise link density 0.34: the share of item pairs that carry a link, counting a structural link in full and a relevance-only link at 0.36. 1.00 means every pair is linked.

Pick up a Lab task

Check whether a fix covers the open issues here, with your own agent. Bring back evidence for maintainers.

Open the Lab

At a glance

Subsystem
gateway
Closed issues
1
Attempts
0 PRs closed without merging

For your agent

The same facts, typed.

cluster/7685.json
cluster/7685.md