PR #64324: fix(feishu): route /btw through out-of-band lanes

• Repository: openclaw/openclaw
• Author: ngutman
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/64324

Description (problem / solution / changelog)

Summary

• Problem: Feishu serializes all same-chat inbound work through a single per-chat queue, so /btw waits behind an active normal reply instead of behaving like an out-of-band side question.
• Why it matters: the BTW UX contract is that side questions should return immediately without waiting for the busy main session to finish.
• What changed: replaced Feishu's chat-only serializer with a sequential-key serializer and routed /btw plus abort-style requests onto dedicated out-of-band keys.
• What did NOT change (scope boundary): core BTW execution, session routing, and normal Feishu same-chat FIFO behavior all stay intact.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #60843
• Related #31807
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: Feishu keyed all inbound work for a chat onto one serializer lane in extensions/feishu/src/monitor.account.ts, so /btw never reached the existing fast inline-command path until the prior message finished.
• Missing detection / guardrail: Feishu had no explicit out-of-band sequencing policy for /btw or /stop, unlike channels that already special-case those commands.
• Contributing context (if known): the existing Feishu FIFO was intentionally added to prevent dropped same-chat messages, so the fix needs to preserve normal ordering while carving out only the truly out-of-band command lanes.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/feishu/src/sequential-key.test.ts, extensions/feishu/src/sequential-queue.test.ts
• Scenario the test should lock in: normal Feishu traffic still serializes on one key, while /btw and /stop resolve to separate keys that can run concurrently with the busy main chat lane.
• Why this is the smallest reliable guardrail: the regression lives in the Feishu ingress scheduler, so key classification plus per-key queue behavior is the narrowest layer that proves the intended bypass without re-testing core BTW logic.
• Existing test that already covers this (if any): src/gateway/server.chat.gateway-server-chat.test.ts already covers core /btw side-result behavior outside Feishu.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• In Feishu, /btw ... no longer waits behind a busy normal message in the same chat.
• In Feishu, /stop also bypasses the normal same-chat lane instead of waiting behind ordinary traffic.
• Normal Feishu same-chat message ordering remains FIFO.

Diagram (if applicable)

Before:
normal message -> Feishu per-chat lane
/btw arrives   -> same Feishu per-chat lane -> waits for normal reply -> delayed side answer

After:
normal message -> Feishu base chat lane
/btw arrives   -> Feishu btw lane -> runs immediately -> side answer

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local Node/pnpm repo workflow
• Model/provider: N/A
• Integration/channel (if any): Feishu
• Relevant config (redacted): default local test config

Steps

1. Send a normal Feishu message that starts a long-running reply.
2. Send /btw <question> in the same Feishu chat while the first reply is still running.
3. Observe whether the side question shares the busy normal chat lane or runs on its own out-of-band lane.

Expected

• /btw runs immediately without waiting behind the normal chat lane.

Actual

• Before this fix, Feishu queued /btw behind the active normal chat task.
• After this fix, Feishu resolves /btw to a dedicated sequential key and no longer blocks it behind ordinary traffic.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: pnpm test extensions/feishu/src/sequential-key.test.ts extensions/feishu/src/sequential-queue.test.ts; pnpm build
• Edge cases checked: /btw missing-message-id fallback key; /stop stays out-of-band; ordinary slash commands like /status remain on the normal chat lane.
• What you did not verify: live Feishu end-to-end behavior against a real account.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: widening the bypass too far could accidentally let stateful slash commands skip intended same-chat ordering.
  • Mitigation: only /btw and abort-style requests get dedicated out-of-band keys; normal messages and ordinary control commands keep the base chat key.

Changed files

• CHANGELOG.md (modified, +1/-0)
• extensions/feishu/src/monitor.account.ts (modified, +12/-22)
• extensions/feishu/src/sequential-key.test.ts (added, +72/-0)
• extensions/feishu/src/sequential-key.ts (added, +25/-0)
• extensions/feishu/src/sequential-queue.test.ts (added, +64/-0)
• extensions/feishu/src/sequential-queue.ts (added, +15/-0)