* fix(feishu): recover CJK filenames from JSON file_name field
Apply recoverUtf8FileNameFromLatin1Header to JSON-derived filenames in
extractFeishuDownloadMetadata, matching the behavior already present for
Content-Disposition headers in decodeDispositionFileName.
Fixes#81103
* fix(feishu): recover inbound CJK filenames
---------
Co-authored-by: Vincent Koc <25068+vincentkoc@users.noreply.github.com>
* [AI] fix(feishu): guard against missing inbound in channelRuntime fallback
When channelRuntime from gateway context is truthy but lacks the inbound
property, the ?? operator still selects it over getFeishuRuntime().channel,
causing TypeError at core.channel.inbound.run().
The ChannelGatewayContext types channelRuntime as ChannelRuntimeSurface
(only guarantees runtimeContexts), but channel.ts casts it to
PluginRuntimeChannel via type assertion. If a partial runtime object
without inbound is provided, the type lie becomes a runtime crash.
Fix: check channelRuntime?.inbound before using it; fall back to
getFeishuRuntime().channel when inbound is absent.
Related to #93453
* [AI] test(feishu): add regression for partial channelRuntime lacking inbound
When channelRuntime has runtimeContexts but no inbound, the guard in
bot.ts should fall back to getFeishuRuntime().channel. Add a test that
passes a partial channelRuntime and verifies dispatch does not crash.
Refs #93453
* fix(feishu): pass card_msg_content_type to get full card content
When reading Feishu interactive card messages via getMessageFeishu,
the API returns a degraded structure (title + 'upgrade client' prompt)
unless card_msg_content_type=user_card_content is passed in params.
Fixes#78289
* fix(feishu): request full card content for message reads
---------
Co-authored-by: Vincent Koc <25068+vincentkoc@users.noreply.github.com>
* fix(feishu): re-resolve route when dynamic agent binding already exists in runtime config
When dynamicAgentCreation is enabled and a binding was previously written
to the config file (e.g. from a prior message), the in-memory cfg may be
stale and not contain the binding. Previously, maybeCreateDynamicAgent
returned { created: false, updatedCfg: cfg } with the stale cfg, and
bot.ts only re-resolved the route when created === true. This caused
subsequent messages to still route to agent:main.
Fix: check runtime.config.current() for the binding when it is missing
from the in-memory cfg. When found, return the runtime's current config
so the caller can re-resolve the route with up-to-date bindings.
Fixes#42837
* fix(feishu): serialize dynamic agent config updates
* fix(feishu): route with refreshed runtime config
* fix(feishu): use current dynamic-agent policy
* fix(feishu): reauthorize refreshed dynamic routes
* fix(feishu): authorize dynamic agent mutations
* fix(feishu): complete account-scoped dynamic routing
* fix(feishu): revalidate current direct routes
* fix(feishu): isolate named-account dynamic agents
* fix(feishu): bound named dynamic agent ids
* docs(feishu): explain legacy dynamic agent cap
* test(feishu): fix dynamic routing check types
---------
Co-authored-by: Vincent Koc <25068+vincentkoc@users.noreply.github.com>
Target Feishu Typing reactions at the inbound message id while preserving reply and thread routing to the topic root.
This keeps the fallback to replyToMessageId for flows without a separate inbound target, and adds regression coverage for topic/replyInThread behavior and synthetic Feishu turn sources.
Based on and credits #67783 by @huiwen01. This replacement branch carries the same user-visible fix forward because #67783 is dirty against main and earlier automation could not update the fork branch with available permissions. This intentionally does not reuse or expand #73958; root_id routing remains separate.
Validation:
- pnpm check:changed
- pnpm -s vitest run extensions/feishu/src/bot.test.ts extensions/feishu/src/reply-dispatcher.test.ts extensions/feishu/src/monitor.reaction.test.ts
- autoreview clean: no accepted/actionable findings
- GitHub checks: 127 pass, 0 fail, 0 pending
Co-authored-by: huiwen01 <89329207+huiwen01@users.noreply.github.com>
Clear cached Feishu clients when the test runtime replaces the SDK, preventing stale clients from leaking across test setup. Adds regression coverage for the SDK swap path. Fixes#83911.
* fix(feishu): add retry with linear backoff for send rate-limit errors
When Feishu returns code 230020 (per-chat rate limit), requestFeishuApi
now retries up to 2 times with linear backoff (500ms, 1000ms). The reply
path (im.message.reply) is also covered via the same retry helper.
Confirmed by a real 20-concurrent-send stress test: all 20 messages
succeed after retry.
Closes#70879
* ci: retrigger CI
* fix(feishu): retry HTTP 429 and code 11232 for message send rate limits
Feishu Open API has three send-time rate limit signals: HTTP 429
(gateway-wide quota), business code 11232 (tenant-level message
service: 100/min, 5/sec), and 230020 (per-chat). Previously only
230020 was retried; HTTP 429 and 11232 propagated as fatal errors.
- Add 11232 to FEISHU_SEND_RATE_LIMIT_CODES.
- In getFeishuSendRateLimitCode, recognize HTTP 429 before reading
the body code so gateway-level limits enter the retry loop.
- Update doc comment listing both gateway and business sources.
* test(feishu): add focused retry coverage for 11232 and HTTP 429
The previous send.retry.test.ts only exercised 230020 / 230006 / non-rate
codes / plain errors. After expanding the retry policy in 90c787096 to
cover code 11232 (tenant-level message rate limit) and gateway-level
HTTP 429, ClawSweeper review #89659 (P2) flagged the tests as no longer
matching the production behavior.
- getFeishuSendRateLimitCode: assert 11232 returns 11232, HTTP 429
returns 429, and HTTP 429 wins over body code when both are present.
- requestFeishuApi: cover 11232 retry-then-success, 429 retry-then-success,
exhaustion paths for both, and a mixed 230020 → 11232 → ok recovery.
* fix(feishu): retry on fulfilled rate-limit response bodies (no-throw)
The Feishu node SDK sometimes resolves a non-throwing response that
carries a rate-limit code in its body (e.g. { code: 11232, msg: ... })
instead of rejecting. requestFeishuApi previously returned that body
straight away and downstream assertFeishuMessageApiSuccess failed once
with no retry — the same shape that issue #28157 fixed earlier on the
typing/reaction path via getBackoffCodeFromResponse.
ClawSweeper review on #89659 (P1, comment-shared.ts:140) flagged the
gap. Mirror the typing-path pattern for the send helper:
- Add getFeishuSendRateLimitCodeFromResponse to classify fulfilled
bodies against FEISHU_SEND_RATE_LIMIT_CODES (230020, 11232).
- In requestFeishuApi, after each fulfilled await, classify before
returning. If the body is a retryable rate limit and there are
attempts left, continue the loop. After exhaustion, wrap the last
fulfilled body into a synthetic AxiosError-shaped error so callers
see the same error shape as the throw path.
- Add 11 focused tests covering fulfilled 11232/230020 retry-then-ok,
exhaustion, mixed throw → fulfilled → ok recovery, and pass-through
for code 0 / non-rate-limit codes.
* fix(feishu): break loop on final-attempt fulfilled rate-limit body
ClawSweeper review on dc8d3be7d (P1, comment-shared.ts:166) caught a
real bug: when the final retry attempt also fulfilled with a rate-limit
body (e.g. { code: 11232, ... }), the guard `attempt < FEISHU_SEND_MAX_RETRIES`
was false so control fell through to `return result` — bypassing the
synthetic-error exhaustion path and handing the rate-limit body to the
caller as if it were a successful response. The fulfilled-exhaustion
test missed this because Vitest's local fs module cache served the
pre-fix shape; running with a fresh cache reproduces the failure.
Split the fulfilled-rate-limit branch so the body is always captured,
then continue on a non-final attempt or break on the final attempt.
Breaking falls through to the synthetic AxiosError-shaped throw below,
which is exactly what the existing exhaustion test asserts.
* fix(feishu): retry on send rate-limit errors 230020/11232/429 (#89659) (thanks @ladygege)
---------
Co-authored-by: marshall.m <marshall.m@binance.com>
Co-authored-by: sliverp <870080352@qq.com>
Summary:
- The PR adds a narrow Feishu runtime-setter entrypoint, wires it into the Feishu setup entry, and adds regression coverage for setup-only runtime registration.
- PR surface: Source +7, Tests +22. Total +29 across 4 files.
- Reproducibility: yes. source inspection gives a high-confidence reproduction path: current Feishu setup-only ... ate when that setter is present. I did not run a live Feishu tenant message repro in this read-only review.
Automerge notes:
- PR branch already contained follow-up commit before automerge: fix(feishu): wire setup runtime setter
Validation:
- ClawSweeper review passed for head befd074ca6.
- Required merge gates passed before the squash merge.
Prepared head SHA: befd074ca6
Review: https://github.com/openclaw/openclaw/pull/89814#issuecomment-4612032021
Co-authored-by: Glenn-Agent <glenn_agent@163.com>
Co-authored-by: clawsweeper <274271284+clawsweeper[bot]@users.noreply.github.com>
Co-authored-by: clawsweeper[bot] <274271284+clawsweeper[bot]@users.noreply.github.com>
Approved-by: takhoffman
Co-authored-by: takhoffman <781889+takhoffman@users.noreply.github.com>
Summary:
- Adds defensive failed-count reads in auto-reply/ACP accounting and Feishu fallback paths, plus a focused regression test, while keeping `ReplyDispatcher.getFailedCounts` required.
- PR surface: Source +24, Tests +35. Total +59 across 5 files.
- Reproducibility: yes. from source inspection. Current main calls `dispatcher.getFailedCounts().final` and si ... issing that method follows a clear TypeError path; the source PR also supplied terminal before/after proof.
Automerge notes:
- PR branch already contained follow-up commit before automerge: fix(auto-reply): guard missing dispatcher getFailedCounts without wea…
Validation:
- ClawSweeper review passed for head 0bdfb4adeb.
- Required merge gates passed before the squash merge.
Prepared head SHA: 0bdfb4adeb
Review: https://github.com/openclaw/openclaw/pull/89318#issuecomment-4598624344
Co-authored-by: Alix-007 <li.long15@xydigit.com>
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: clawsweeper <274271284+clawsweeper[bot]@users.noreply.github.com>
Co-authored-by: clawsweeper[bot] <274271284+clawsweeper[bot]@users.noreply.github.com>
Approved-by: takhoffman
Co-authored-by: takhoffman <781889+takhoffman@users.noreply.github.com>
Preserve long Feishu streaming replies by falling oversized finals back to chunked message/static-card delivery instead of closing through an over-limit streaming CardKit payload.
Keeps late-final suppression after a streaming card closes, and uses markdown-aware chunking for static card fallback replies.
Fixes#88631.
Co-authored-by: Ted Li <tl2493@columbia.edu>
Vincent Koc