Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: Synthetic `card-action-c-*` message IDs cause delivery layer 400 errors [1 comments, 2 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#71673•Fetched 2026-04-26 05:09:55
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
0
Author
eddy1068eddy1068
Participants
eddy1068eddy1068steipetesteipete
Timeline (top)
closed ×1commented ×1labeled ×1

When the agent replies to a Feishu card action callback, OpenClaw uses the synthetic message ID (card-action-{token}) as the open_message_id for Feishu API calls. Feishu rejects these with HTTP 400, causing 10+ retries and a 3–6 second delay before the message finally delivers without reply_to.

Root Cause

Root cause: buildSyntheticMessageEvent (monitor-DDkD5r4p.js ~L2225) sets message_id: \card-action-${event.token}\`on the synthetic event. This ID propagates downstream asreplyToMessageId` and gets passed to the Feishu reply API, which rejects any non-real message ID.
Suggested fix: when messageId starts with card-action-, skip reply_to and fall back to plain send immediately. Alternatively, use context.open_message_id from the callback event as the actual reply target.

Code Example

Root cause: buildSyntheticMessageEvent (monitor-DDkD5r4p.js ~L2225) sets message_id: \card-action-${event.token}\`on the synthetic event. This ID propagates downstream asreplyToMessageId` and gets passed to the Feishu reply API, which rejects any non-real message ID.
Suggested fix: when messageId starts with card-action-, skip reply_to and fall back to plain send immediately. Alternatively, use context.open_message_id from the callback event as the actual reply target.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When the agent replies to a Feishu card action callback, OpenClaw uses the synthetic message ID (card-action-{token}) as the open_message_id for Feishu API calls. Feishu rejects these with HTTP 400, causing 10+ retries and a 3–6 second delay before the message finally delivers without reply_to.

Steps to reproduce

  1. Configure OpenClaw with Feishu channel (WebSocket mode)
  2. Trigger a card action callback (requires Issue 1 fix to be in place, otherwise callbacks are dropped before reaching this layer)
  3. Agent responds to the card action
  4. Observe gateway logs: repeated Invalid ids: [card-action-...] 400 errors before message eventually delivers

Expected behavior

Agent reply delivers immediately without retry loops. If reply_to is not applicable (no real message ID available), the system falls back to plain send on the first attempt.

Actual behavior

Gateway uses the synthetic card-action-{token} ID as replyToMessageId. Feishu rejects it with HTTP 400. System retries 10+ times before falling back to plain send, adding 3–6 seconds of unnecessary delay to every card action response.

OpenClaw version

2026.4.21

Operating system

Ubuntu 22.04 / Linux 6.8.0

Install method

npm global

Model

N/A (issue is in delivery layer, not model)

Provider / routing chain

N/A

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Root cause: buildSyntheticMessageEvent (monitor-DDkD5r4p.js ~L2225) sets message_id: \card-action-${event.token}\`on the synthetic event. This ID propagates downstream asreplyToMessageId` and gets passed to the Feishu reply API, which rejects any non-real message ID.
Suggested fix: when messageId starts with card-action-, skip reply_to and fall back to plain send immediately. Alternatively, use context.open_message_id from the callback event as the actual reply target.

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

Modify the buildSyntheticMessageEvent function to handle synthetic message IDs starting with "card-action-" by skipping reply_to and falling back to plain send immediately.

Guidance

  • Identify the buildSyntheticMessageEvent function in monitor-DDkD5r4p.js and modify it to check if the messageId starts with "card-action-".
  • If it does, skip setting replyToMessageId and use plain send instead.
  • Alternatively, use context.open_message_id from the callback event as the actual reply target.
  • Verify the fix by triggering a card action callback and checking the gateway logs for the absence of repeated "Invalid ids" 400 errors.

Example

if (messageId.startsWith('card-action-')) {
  // Skip reply_to and fall back to plain send
  // or use context.open_message_id as the reply target
} else {
  // Proceed with setting replyToMessageId
}

Notes

The suggested fix assumes that the context.open_message_id from the callback event is a valid reply target. If this is not the case, additional modifications may be necessary.

Recommendation

Apply the workaround by modifying the buildSyntheticMessageEvent function to handle synthetic message IDs starting with "card-action-". This should prevent the repeated 400 errors and reduce the delay in delivering agent replies.

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

Agent reply delivers immediately without retry loops. If reply_to is not applicable (no real message ID available), the system falls back to plain send on the first attempt.

#api#pipeline error#runtime error#dependency conflict#environment setup

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]: Synthetic `card-action-c-*` message IDs cause delivery layer 400 errors [1 comments, 2 participants]