Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: QQBot channel does not apply updated bindings until gateway restart

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…

QQBot routing does not reflect updated bindings at runtime; new bindings appear in CLI but are not evaluated until gateway restart.

Root Cause

QQBot routing does not reflect updated bindings at runtime; new bindings appear in CLI but are not evaluated until gateway restart.

Code Example

CLI output:

openclaw agents list --bindings

Shows peer binding:

qqbot accountId=study peer=direct:480562E9913A985D4A79822A643E27B6 → tutor_...

Runtime log before restart:

bindings=1
matchedBy=binding.account

Runtime log after restart:

bindings=2
matchedBy=binding.peer
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

QQBot routing does not reflect updated bindings at runtime; new bindings appear in CLI but are not evaluated until gateway restart.

Steps to reproduce

  1. Start OpenClaw 2026.4.15 with QQBot configured
  2. Add a peer-specific binding to bindings[]
  3. Verify with:openclaw agents list --bindings (peer binding is present)
  4. Send a QQBot C2C message
  5. Observe routing logs

Expected behavior

Routing evaluates all bindings and matches peer binding before account binding, consistent with CLI output.

Actual behavior

Runtime routing only evaluates one binding (account-level), peer binding is not included: [routing] resolveAgentRoute ... bindings=1 [routing] binding: agentId=study accountPattern=study peer=none [routing] match: matchedBy=binding.account agentId=study After openclaw gateway restart, routing becomes correct: bindings=2 binding: tutor_... (peer match) binding: study (account match) matchedBy=binding.peer

OpenClaw version

2026.4.15

Operating system

Ubuntu (Docker container)

Install method

Docker (Ubuntu image)

Model

modelstudio/qwen3.5-plus

Provider / routing chain

openclaw -> modelstudio/qwen3.5-plus

Additional provider/model setup details

QQBot channel configured with accountId=study. Peer ID comes from event.author.user_openid (C2C message).

Logs, screenshots, and evidence

CLI output:

openclaw agents list --bindings

Shows peer binding:

qqbot accountId=study peer=direct:480562E9913A985D4A79822A643E27B6 → tutor_...

Runtime log before restart:

bindings=1
matchedBy=binding.account

Runtime log after restart:

bindings=2
matchedBy=binding.peer

Impact and severity

Affected: QQBot users with dynamic bindings Severity: Medium (breaks expected routing behavior) Frequency: Always reproducible after binding change without restart Consequence: Messages routed to wrong agent until gateway restart

Additional information

Bindings are marked as dynamic (no restart required), but QQBot channel appears to use a config snapshot captured at startup, causing CLI and runtime to diverge.

extent analysis

TL;DR

The QQBot routing issue can be temporarily resolved by restarting the OpenClaw gateway after updating bindings.

Guidance

  • The problem seems to stem from the QQBot channel using a config snapshot from startup, which doesn't update dynamically with new bindings.
  • To verify the issue, check the runtime logs for bindings=1 and matchedBy=binding.account before restarting the gateway, and bindings=2 and matchedBy=binding.peer after restarting.
  • Consider implementing a mechanism to refresh the config snapshot after binding updates, to avoid the need for a gateway restart.
  • Review the OpenClaw documentation to see if there are any configuration options or APIs that can be used to update the bindings dynamically without requiring a restart.

Example

No code snippet is provided as the issue seems to be related to the configuration and behavior of the OpenClaw gateway and QQBot channel, rather than a specific code problem.

Notes

The provided information suggests that the issue is specific to the OpenClaw version 2026.4.15 and the modelstudio/qwen3.5-plus model, and may not be applicable to other versions or models.

Recommendation

Apply workaround: Restart the OpenClaw gateway after updating bindings, until a more permanent solution can be implemented to dynamically update the config snapshot. This is because the current behavior causes incorrect routing, and restarting the gateway ensures that the updated bindings are reflected in the routing decisions.

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…

FAQ

Expected behavior

Routing evaluates all bindings and matches peer binding before account binding, consistent with CLI output.

#chain error#conversation history#tool integration#LLM response#prompt template

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 - 💡(How to fix) Fix [Bug]: QQBot channel does not apply updated bindings until gateway restart