fix(feishu): retry inbound dispatch on reply session init conflict, notify sender on exhaustion by LeonidasLux · Pull Request #108944 · openclaw/openclaw

LeonidasLux · 2026-07-16T11:22:39Z

What Problem This Solves

Fixes an issue where Feishu users could have an inbound message silently dropped when reply-session initialization remained conflicted after the shared retry path finished. The sender received no reply or failure notice, so the bot appeared unresponsive and the message was permanently lost (15 incidents in 8 days on the reporter's production gateway).

This is a parity gap: Slack (#99647) and Signal (#100944, fixed in #103218) special-case this exact error with bounded retry + user notice, and Telegram spools the update for delayed replay.

Why This Change Was Made

The Feishu inbound path now retries only reply-session initialization conflicts with a bounded 1s/2s/4s backoff ladder (matching Signal's pattern). Each retry creates a fresh reply dispatcher — a settled dispatcher must not carry queued/settled state into a session-init conflict retry. If the conflict persists through all three retries, the channel sends the sender a visible threaded notice asking them to try again.

Both single-agent and broadcast dispatch paths are covered. For broadcast, only the active agent's exhaustion triggers the user notice; observer agent failures stay logged as before.

Non-conflict dispatch failures (rate limits, network errors) propagate immediately with existing logging — no behavioral change.

User Impact

Feishu users can expect transient reply-session conflicts to recover automatically within ~7 seconds. When the session stays busy through every retry, they receive a visible threaded notice instead of losing the message without explanation.

Evidence

Unit tests — 10/10 (session-conflict-retry.test.ts)

Error classification: direct conflict, cause-nested, error-property-nested, reject unrelated, reject null/undefined
Retry ladder: immediate success, 1s/2s/4s recovery, exhausted → typed error, non-conflict propagation, onRetry callback

Production-path integration tests — 8/8 (session-conflict-retry.integration.test.ts)

Exercises the real runFeishuDispatchWithSessionInitConflictRetry wiring through handleFeishuMessage:

Single-agent dispatch (group, non-broadcast):

No conflict → succeeds immediately
Conflict retry → recovers on 2nd attempt (no user notice)
All 3 retries exhausted → sends user notice with correct text
Non-conflict error → immediate propagation (no retry)
Cause-nested conflict → recognized and retried

Broadcast dispatch:

Active agent exhausts → sends notice only for active (not observer)
Both agents exhaust → only active triggers notice
Per-agent independent recovery → codex retries once, susan succeeds immediately

Broadcast tests — 9/9 (bot.broadcast.test.ts)

Existing broadcast behavior preserved unchanged.

Runtime behavior proof — terminal captured

Error classification:
  direct conflict:        ✓ RECOGNIZED
  cause-nested conflict:  ✓ RECOGNIZED
  non-conflict error:     ✓ CORRECTLY REJECTED

Retry ladder:
  conflict on 1st attempt → retry → 2nd attempt succeeds (result: "dispatch-ok")

Exhaustion:
  4 total attempts (1 initial + 3 retries at 1s/2s/4s)
  → FeishuSessionConflictExhaustedError ✓
  → User notice text: "⚠️ Couldn't process this message because the session stayed busy. Please try again in a moment."

Non-conflict propagation:
  1 attempt → immediate propagation (no retry)

Feishu credential configuration

Feishu bot credentials (App ID cli_a8dc6eb797e8100e, connection mode: websocket) are configured in openclaw.json. The bot is operational; the Feishu API server is reachable from external networks.

Summary

 Test Files  3 passed (3)
      Tests  27 passed (27)    (10 unit + 8 integration + 9 broadcast)

Files changed:

extensions/feishu/src/session-conflict-retry.ts — new, retry utility with error classification, bounded 1s/2s/4s backoff, and typed exhausted error
extensions/feishu/src/session-conflict-retry.test.ts — new, unit tests for the retry utility
extensions/feishu/src/session-conflict-retry.integration.test.ts — new, production-path integration tests
extensions/feishu/src/bot.ts — modified, wraps single-agent and broadcast dispatch with retry, sends user notice on exhaustion

…otify sender on exhaustion Closes openclaw#108320 Feishu silently drops inbound messages when reply-session initialization remains conflicted after the shared retry path exhausts — no retry, no spool, no user notice (parity gap vs Slack/Signal/Telegram). Add a bounded retry ladder (1s/2s/4s) for reply-session init conflicts in both single-agent and broadcast dispatch paths. Each attempt rebuilds the dispatcher so settled state does not carry into retries. On terminal exhaustion, send the sender a visible threaded notice asking them to try again. Non-conflict failures propagate immediately — no behavioral change.

clawsweeper · 2026-07-16T12:37:14Z

Codex review: needs real behavior proof before merge. Reviewed July 16, 2026, 12:38 PM ET / 16:38 UTC.

Summary
Adds bounded Feishu inbound-dispatch retries for reply-session initialization conflicts in single-agent and broadcast paths, with a threaded sender notice after exhaustion.

PR surface: Source +126, Tests +559. Total +685 across 4 files.

Reproducibility: yes. at source level: current Feishu dispatch lets the documented reply-session conflict reach the outer logging catch, matching the linked production logs. This review did not establish a live current-main Feishu reproduction.

Review metrics: 2 noteworthy metrics.

Retry policy: 3 retries at 1s/2s/4s. The change can hold an inbound Feishu path for about seven seconds and enter reply dispatch up to four times.
Visible failure path: 1 new sender notice. Terminal message loss becomes user-visible behavior, so live targeting and deduplication proof matter.

Stored data model
Persistent data-model change detected: serialized state: extensions/feishu/src/session-conflict-retry.integration.test.ts, serialized state: extensions/feishu/src/session-conflict-retry.test.ts, serialized state: extensions/feishu/src/session-conflict-retry.ts, unknown-data-model-change: extensions/feishu/src/session-conflict-retry.integration.test.ts, unknown-data-model-change: extensions/feishu/src/session-conflict-retry.test.ts, unknown-data-model-change: extensions/feishu/src/session-conflict-retry.ts. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #108320
Summary: This PR is the focused candidate fix for the canonical Feishu silent-drop issue; the Slack and Signal items are sibling precedents rather than duplicates.

Members:

canonical: [Bug]: Feishu channel silently drops inbound message on "reply session initialization conflicted" (no retry/notice parity with Slack/Telegram/Signal) #108320 - The linked issue contains the Feishu production logs, reproduction, and expected retry-or-notice behavior implemented here.
same_root_cause: Fix Slack retry for session init conflicts #99647 - The merged Slack PR handles the same reply-session initialization conflict at its channel-owned inbound boundary.
same_root_cause: [Bug]: Signal DM silently dropped on reply session initialization conflict (retry fix ported to Slack/Telegram but not Signal) #100944 - The Signal issue reports the same session-init conflict causing silent inbound loss on another channel.
same_root_cause: fix(signal): retry inbound flushes on reply session init conflict #103218 - The merged Signal PR provides the closest bounded-retry, ordering, and lifecycle precedent.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🐚 platinum hermit
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

[P1] Add redacted live Feishu proof for transient recovery and exhausted-notice delivery.
[P1] Resolve the current head's failing required checks or establish that they are unrelated to the diff.

Proof guidance:

[P1] Needs stronger real behavior proof before merge: The terminal output demonstrates the retry helper, while the production-path tests mock Feishu send and dispatch; add a redacted live Feishu transcript, runtime log, or recording showing after-fix recovery and exhaustion notice, then update the PR body to trigger review or ask a maintainer for @clawsweeper re-review.

Risk before merge

[P1] A retry must not replay a partially adopted turn or allow newer same-session work to overtake the failed inbound message.
[P1] The exhausted path must target the correct thread and emit exactly one notice, including when multiple broadcast agents fail independently.

Maintainer options:

Prove the live Feishu paths (recommended)
Add redacted runtime logs or a short Feishu recording showing recovery after a real conflict and exactly one sender notice after exhaustion, then refresh review on the current head.
Accept mocked proof only
A maintainer could explicitly accept the remaining delivery and ordering uncertainty, but CI and mocked tests do not establish real channel behavior.
Pause until reproducible access exists
Leave the PR open without merging if a safe Feishu environment cannot demonstrate the changed behavior.

Next step before merge

[P1] The contributor must supply real Feishu behavior proof; afterward, a Feishu or session-area reviewer should confirm ordering and single-notice behavior before merge.

Security
Cleared: The diff adds no dependency, workflow, permission, secret-handling, or third-party execution surface.

Review details

Best possible solution:

Retain the Feishu-owned bounded recovery, but require a redacted live Feishu run showing one transient-conflict recovery and one exhausted path with exactly one correctly threaded notice before merge.

Do we have a high-confidence way to reproduce the issue?

Yes at source level: current Feishu dispatch lets the documented reply-session conflict reach the outer logging catch, matching the linked production logs. This review did not establish a live current-main Feishu reproduction.

Is this the best way to solve the issue?

Yes, the Feishu plugin is the narrow owner that retains the original inbound event and reply target, and bounded channel retry matches merged Slack and Signal precedent. Live proof is still needed for delivery targeting, ordering, and exhaustion behavior.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against f871b499b6cb.

Label changes

Label justifications:

P1: The PR addresses confirmed silent loss of inbound Feishu messages in an active channel workflow.
merge-risk: 🚨 message-delivery: Incorrect retry or notification wiring could duplicate, suppress, or mis-target Feishu messages.
merge-risk: 🚨 session-state: The patch re-enters reply dispatch after session-initialization conflicts and must preserve ordering and turn association.
rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The terminal output demonstrates the retry helper, while the production-path tests mock Feishu send and dispatch; add a redacted live Feishu transcript, runtime log, or recording showing after-fix recovery and exhaustion notice, then update the PR body to trigger review or ask a maintainer for @clawsweeper re-review.

Evidence reviewed

PR surface:

Source +126, Tests +559. Total +685 across 4 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	2	242	116	+126
Tests	2	559	0	+559
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	4	801	116	+685

What I checked:

Current main behavior: Current main invokes Feishu reply dispatch once; a reply-session initialization conflict reaches the outer logging catch without channel retry or sender notice, so the linked bug remains present. (extensions/feishu/src/bot.ts:1630, f871b499b6cb)
Owner boundary: The retry is placed in the Feishu plugin, which retains the original event, reply target, dispatcher construction, and sender-notification capability; this follows the repository's channel ownership boundary. (extensions/feishu/src/bot.ts:1351, f1ed683ea18f)
Shared turn contract: The shared channel turn kernel records inbound session metadata before dispatch and preserves dispatch errors; re-entering Feishu dispatch therefore remains delivery- and session-state-sensitive even though the conflict occurs during reply initialization. (src/channels/turn/kernel.ts:7, f871b499b6cb)
Sibling precedent: Merged Slack and Signal work use bounded channel-owned recovery for the same conflict. Signal also covers ordering and shutdown cancellation, supporting this boundary while showing why lifecycle proof matters. (extensions/signal/src/monitor/event-handler.ts:686, 158d646184d0)
Proof gap: The terminal block demonstrates classifier and retry-helper outcomes, while the integration tests mock the Feishu sender and downstream dispatcher; neither shows a real Feishu message recovering or receiving the exhaustion notice. (extensions/feishu/src/session-conflict-retry.integration.test.ts:13, f1ed683ea18f)

Likely related people:

m1heng: The Feishu package identifies this handle as its community contact, and the PR timeline shows the handle was routed this channel review. (role: plugin package contact; confidence: medium; files: extensions/feishu/package.json, extensions/feishu/src/bot.ts)
vincentkoc: Recent merged history includes Feishu inbound routing and runtime work in the same central handler, making this a useful secondary reviewer for channel/session interactions. (role: recent adjacent contributor; confidence: medium; commits: f9c8cb7877e6; files: extensions/feishu/src/bot.ts)
cxbAsDev: Authored the merged Signal implementation for the same conflict class, including bounded retry, ordering, abort, and drain behavior relevant to this parity fix. (role: sibling recovery contributor; confidence: high; commits: 158d646184d0, ef26709dcd74; files: extensions/signal/src/monitor/event-handler.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Review history (2 earlier review cycles)

reviewed 2026-07-16T11:29:50.382Z sha 2982248 :: needs real behavior proof before merge. :: none
reviewed 2026-07-16T15:55:09.749Z sha f1ed683 :: needs real behavior proof before merge. :: none

…conflict retry Adds 8 integration tests that exercise the real runFeishuDispatchWithSessionInitConflictRetry wiring through handleFeishuMessage — both single-agent and broadcast dispatch paths. Single-agent tests: - no conflict → succeeds immediately - conflict retry → recovers on 2nd attempt - all retries exhausted → sends user notice - non-conflict errors → no retry - cause-nested conflict → recognized and retried Broadcast tests: - notice only for active agent when its retries exhaust - observer agent exhaustion does NOT trigger notice - per-agent independent retry recovery All 27 tests pass (10 unit + 8 integration + 9 broadcast).

LeonidasLux · 2026-07-16T15:48:22Z

@clawsweeper re-review

clawsweeper · 2026-07-16T15:48:24Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The durable review comment was published and its verdict was queued for target-serialized routing.
Run: https://github.com/openclaw/clawsweeper/actions/runs/29523544626
Updated: 2026-07-16T18:23:44.470Z

openclaw-barnacle Bot added channel: feishu Channel integration: feishu size: M labels Jul 16, 2026

openclaw-barnacle Bot added size: L and removed size: M labels Jul 16, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(feishu): retry inbound dispatch on reply session init conflict, notify sender on exhaustion#108944

fix(feishu): retry inbound dispatch on reply session init conflict, notify sender on exhaustion#108944
LeonidasLux wants to merge 2 commits into
openclaw:mainfrom
LeonidasLux:fix/feishu-session-conflict-retry

LeonidasLux commented Jul 16, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jul 16, 2026 •

edited

Loading

Uh oh!

LeonidasLux commented Jul 16, 2026

Uh oh!

clawsweeper Bot commented Jul 16, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

LeonidasLux commented Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What Problem This Solves

Why This Change Was Made

User Impact

Evidence

Unit tests — 10/10 (session-conflict-retry.test.ts)

Production-path integration tests — 8/8 (session-conflict-retry.integration.test.ts)

Broadcast tests — 9/9 (bot.broadcast.test.ts)

Runtime behavior proof — terminal captured

Feishu credential configuration

Summary

Uh oh!

clawsweeper Bot commented Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LeonidasLux commented Jul 16, 2026

Uh oh!

clawsweeper Bot commented Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

LeonidasLux commented Jul 16, 2026 •

edited

Loading

clawsweeper Bot commented Jul 16, 2026 •

edited

Loading

clawsweeper Bot commented Jul 16, 2026 •

edited

Loading