Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Diagnostics gap: no operator-facing way to confirm which routing rule matched for Feishu group chats [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#54952•Fetched 2026-04-08 01:34:10
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
EronFanEronFan
Participants
EronFanEronFan
Timeline (top)
cross-referenced ×1

Fix Action

Fix / Workaround

Options could include (not limited to):

  • Adding a `routing.matchedRule` field to the dispatch log entry
  • Including the binding index/name in the session key canonical form when a binding was responsible
  • A gateway doctor/diagnostics command that explains the routing decision for a given inbound message

PR fix notes

PR #55013: docs(channels/feishu): clarify routing fallback chain and session key relationship

Description (problem / solution / changelog)

Summary

Adds missing documentation about the Feishu routing fallback behavior:

  1. feishu.md: Explains what happens when no explicit binding matches — the gateway falls back to the default account, then to channels.defaults.groupPolicy. Also clarifies that the canonical session key reflects the final destination but does not encode which rule (binding or fallback) was responsible.

  2. configuration-reference.md: Updates the channels.defaults.groupPolicy description to clarify its role in the fallback chain.

Motivation

When a Feishu group message arrives and the operator sees it handled by the wrong agent, there is no operator-facing way to tell whether:

  • No binding exists and the fallback chose the wrong default
  • A binding exists but has the wrong agent assignment
  • The session key format created a routing discontinuity

This aligns with issue #54952 (diagnostics gap), reducing the gap by making the fallback behavior explicitly documented.

Thanks

Changed files

  • docs/channels/feishu.md (modified, +2/-0)
  • docs/gateway/configuration-reference.md (modified, +1/-1)
  • docs/zh-CN/channels/feishu.md (modified, +2/-0)
RAW_BUFFERClick to expand / collapse

Problem Summary

When a Feishu group chat message arrives and the gateway routes it, there is no operator-facing way to confirm whether the message matched an explicit binding entry or fell back to the default agent policy.

The routing may be working correctly, but the operator has no visibility into which rule won.

What the docs say

Bindings (`channels.feishu.bindings[]`) are the primary routing mechanism for Feishu DMs and groups:

Use `bindings` to route Feishu DMs or groups to different agents.

Fallback (`channels.defaults.groupPolicy`) is the fallback group policy when a provider-level `groupPolicy` is unset. When no explicit binding matches, the gateway falls back to the configured default account/agent.

The session key that gets created reflects the outcome (which agent handled it), but does not encode which rule was matched.

The gap

The canonical session key (e.g., `feishu:g-{chatId}`) only tells you the final destination — it does not expose:

  1. Which routing rule matched — explicit binding vs. fallback vs. default account
  2. The binding entry (if any) that was responsible for the match
  3. The fallback chain — when multiple fallback layers exist (account-level, provider-level, global default), which one resolved the routing

An operator who sees a message handled by the wrong agent cannot diagnose whether:

  • No binding exists and the fallback chose the wrong default
  • A binding exists but has the wrong `accountId` or agent assignment
  • The session key format itself changed and created a routing discontinuity

What this report is NOT asserting

  • This report is not asserting wrong routing. The actual routing behavior may be fully correct.
  • This report is not a request to change the routing logic.
  • This report is asking for a clearer operator-facing way to confirm which routing rule won.

Suggested improvement

Expose the matched routing rule in gateway diagnostics/logs so that an operator can answer questions like:

  • "Did this message match a binding, or hit the fallback?"
  • "Which binding entry matched (if any)?"
  • "Which fallback layer resolved the routing?"

Options could include (not limited to):

  • Adding a `routing.matchedRule` field to the dispatch log entry
  • Including the binding index/name in the session key canonical form when a binding was responsible
  • A gateway doctor/diagnostics command that explains the routing decision for a given inbound message

Environment

  • OpenClaw version: latest (main branch)
  • Feishu plugin: configured with multiple accounts and/or bindings
  • Scenario: group chat with no explicit binding → appears to fall back to default agent

Thanks

extent analysis

Fix Plan

To address the issue, we can modify the gateway to include the matched routing rule in its diagnostics/logs. Here are the steps:

  • Add a routing.matchedRule field to the dispatch log entry to indicate whether the message matched a binding or hit the fallback.
  • Include the binding index/name in the session key canonical form when a binding was responsible.

Example code snippet in Python:

# In the dispatch log entry
log_entry = {
    # ... existing fields ...
    'routing': {
        'matchedRule': 'binding' if binding_match else 'fallback',
        'bindingIndex': binding_index if binding_match else None
    }
}

# In the session key canonical form
if binding_match:
    session_key = f"feishu:g-{chatId}:{binding_index}"
else:
    session_key = f"feishu:g-{chatId}"
  • Implement a gateway doctor/diagnostics command to explain the routing decision for a given inbound message.

Example code snippet in Python:

def diagnose_routing(message):
    # ... existing logic to determine the matched routing rule ...
    if binding_match:
        print(f"Message matched binding {binding_index}")
    else:
        print("Message hit fallback")
    # ... existing logic to print the routing decision ...

Verification

To verify that the fix worked, operators can check the dispatch log entries and session keys to confirm which routing rule was matched. They can also use the gateway doctor/diagnostics command to explain the routing decision for a given inbound message.

Extra Tips

  • Make sure to update the documentation to reflect the changes to the dispatch log entries and session keys.
  • Consider adding additional logging or monitoring to track the performance of the routing rules and identify potential issues.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#docker error#permission error#memory optimization#batch processing#GPU compatibility

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Diagnostics gap: no operator-facing way to confirm which routing rule matched for Feishu group chats [1 pull requests, 1 participants]