openclaw - ✅(Solved) Fix [Bug]: OpenClaw send message with big file via wecom show gateway timeout after 10000ms [1 pull requests, 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#74164Fetched 2026-04-30 06:27:51
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Timeline (top)
cross-referenced ×2labeled ×2commented ×1

OpenClaw send message with big file via wecom show error: gateway timeout after 10000ms

Error Message

OpenClaw send message with big file via wecom show error: gateway timeout after 10000ms Error: gateway timeout after 10000ms

Root Cause

OpenClaw send message with big file via wecom show error: gateway timeout after 10000ms

Fix Action

Fixed

PR fix notes

PR #74169: fix: increase default gateway call timeout from 10000ms to 15000ms

Description (problem / solution / changelog)

Summary

Fixes openclaw/openclaw#74164 - Gateway timeout after 10000ms when sending large files via wecom channel.

The issue was that when no explicit gateway.handshakeTimeoutMs is configured and no OPENCLAW_HANDSHAKE_TIMEOUT_MS env var is set, the resolveGatewayCallTimeout function would return undefined for resolvedHandshakeTimeoutMs and fall back to a hardcoded 10000ms.

This is too short for large file uploads (e.g., 10MB files), causing the gateway call to timeout prematurely.

Changes

  • Modified resolveGatewayCallTimeout in src/gateway/call.ts to always call resolvePreauthHandshakeTimeoutMs() instead of returning undefined when no explicit config/env is set
  • This ensures the proper default of 15000ms (DEFAULT_PREAUTH_HANDSHAKE_TIMEOUT_MS) is used instead of the hardcoded 10000ms
  • Updated the timeoutMs logic to use resolvedHandshakeTimeoutMs when either hasEnvHandshakeTimeout is true OR when hasConfiguredHandshakeTimeout is true AND resolvedHandshakeTimeoutMs > 10000

Testing

Existing tests verify that:

  • When handshakeTimeoutMs: 30000 is set in config, the timeout is 30000ms
  • When OPENCLAW_HANDSHAKE_TIMEOUT_MS=30000 is set in env, the timeout is 30000ms
  • These behaviors are preserved by the fix

Fixes openclaw/openclaw#74164

Changed files

  • src/gateway/call.ts (modified, +8/-6)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

OpenClaw send message with big file via wecom show error: gateway timeout after 10000ms

Steps to reproduce

Run the following command in the Linux Terminal (the attach file is about 10M) : openclaw message send --channel wecom --target XXX --message "hello, this is the result file" --media /home/cyc/.openclaw/workspace-worker/tmp/FT200C1211_20260429.zip

OpenClaw version: OpenClaw 2026.4.15 (041266a) wecom-openclaw-plugin version: 2026.4.27

Expected behavior

file send successful

Actual behavior

Screen output is in the following: 14:38:26 [plugins] hook runner initialized with 1 registered hooks 14:38:26 [plugins] hook runner initialized with 1 registered hooks │ 14:38:31 [bedrock-mantle-discovery] Mantle IAM token generation unavailable ◇
Error: gateway timeout after 10000ms Gateway target: ws://127.0.0.1:18789 Source: local loopback Config: /home/cyc/.openclaw/openclaw.json Bind: loopback

OpenClaw version

2026.4.15

Operating system

Debian11

Install method

No response

Model

qwen3.5-plus

Provider / routing chain

openclaw

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

Increase the timeout value for the OpenClaw send message command to handle large file transfers.

Guidance

  • Verify the current timeout setting in the OpenClaw configuration file (/home/cyc/.openclaw/openclaw.json) to confirm it is set to 10000ms.
  • Consider increasing the timeout value to a higher number (e.g., 30000ms) to accommodate larger file transfers.
  • Check the wecom-openclaw-plugin version (2026.4.27) to ensure it is compatible with the OpenClaw version (2026.4.15).
  • Test the send message command with a smaller file to isolate the issue and confirm it is related to file size.

Example

No code snippet is provided as the issue is related to configuration and file transfer.

Notes

The solution assumes that the issue is caused by the timeout value being too low for large file transfers. If increasing the timeout value does not resolve the issue, further investigation into the wecom-openclaw-plugin and OpenClaw configuration may be necessary.

Recommendation

Apply workaround: Increase the timeout value to a higher number (e.g., 30000ms) to handle large file transfers, as this is a non-invasive change that can be easily reverted if it does not resolve the issue.

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

file send successful

Still need to ship something?

×6

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

Back to top recommendations

TRENDING