Bug: Feishu API errors silently swallowed, agent receives outcome=completed on failure

Description

When the Feishu API returns an error (e.g., HTTP 400 with code=230099), the gateway logs the error but still returns outcome=completed to the agent. The agent has no way to know the message was not delivered to the user.

Steps to Reproduce

Agent generates a reply containing many markdown tables (exceeding Feishu's card table limit)
Gateway calls Feishu API to send the message
Feishu returns HTTP 400: code=230099, msg="card table number over limit"
Gateway logs: [error]: code: 230099
Gateway returns to agent: outcome=completed, replies=1

Expected Behavior

Gateway should return outcome=failed when Feishu API returns an error
Error details (code + message) should be included in the response
Agent should be able to retry or notify the user

Actual Behavior

Error is logged but not propagated to agent
outcome=completed is returned unconditionally
Agent believes the message was delivered successfully
User receives nothing

Root Cause

In reply-dispatcher, queuedCounts is incremented on enqueue but not decremented on failure. The onError callback only logs the error without re-throwing or updating the dispatch result. The outcome is set to "completed" unconditionally at the end of the dispatch flow.

Suggested Fix

Gateway side:

When Feishu API returns HTTP 4xx/5xx or code != 0, set outcome=failed
Include structured error info in response: {outcome, error_code, error_msg}
Track failedCounts in dispatch result

Optional hardening:

Pre-validate card content (e.g., table count) before sending
Add monitoring for "success reported but downstream failed" scenarios

Impact

Users may believe their messages were delivered when they were not. This affects any Feishu integration where the agent generates content that triggers API errors.

Codex review: this still needs some work. Reviewed October 3, 2026, 1:55 AM ET / 05:55 UTC.

Summary
Delivery accounting and table-limit fallback have improved, but current main still records a completed processing outcome independently of delivery failure and does not expose provider error details through that outcome. The earlier repair PR closed unmerged, so the remaining reporting request merits a focused contract decision.

Likely related people: steipete and joshavant, medium-confidence routing candidates from shared delivery history.

Reproducibility: unclear. for the exact agent-facing claim: source proves that a successful agent run with failed delivery can retain completed processing diagnostics, but no live run or model-visible response was verified.

Maintainer decision needed

Question	Recommendation
Should delivery failures be exposed separately through the existing settled-receipt contract, or should they change the shared processed outcome?	Keep separate run and delivery outcomes: Define sanitized delivery-error feedback at the existing settlement boundary and identify its agent-facing consumer.

Why: Current code deliberately distinguishes agent execution from transport settlement; redefining completed would affect sibling channels and public consumers, while the requested model feedback has no identified entrypoint.

Next step
Resolve the shared reporting contract and identify the model-visible consumer before scoping a repair; no new fix PR should be dispatched yet.

Review details

Best possible solution:

Use the existing settled-receipt owner to expose sanitized delivery failures separately from agent-run completion, preserving duplicate-safe recovery.

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

Unclear for the exact agent-facing claim: source proves that a successful agent run with failed delivery can retain completed processing diagnostics, but no live run or model-visible response was verified.

Is this the best way to solve the issue?

The proposed unconditional failed outcome is not yet the best-supported repair; extending the existing settlement contract preserves the distinction between execution failure, rejected delivery, and ambiguous delivery.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

The report does not identify the agent-facing entrypoint that receives outcome=completed; current source establishes that processing diagnostics can say completed after delivery failure, but not that the model receives that diagnostic.
Changing the shared processing outcome or exposing provider errors requires a defined contract for partial delivery, ambiguous sends, recovery-owned retries, and sanitized error details.

Codex review notes: model internal, reasoning medium; reviewed against 6a565393916d.

Label changes

Label changes:

No label changes.

Label justifications:

P1: Failed channel delivery can leave users without an answer while processing diagnostics still indicate completion.
impact:message-loss: The report concerns rejected Feishu replies and missing delivery feedback.

Evidence reviewed

What I checked:

Processing outcome remains independent of delivery: The finalizer selects error for a failed agent run or question failure, skipped for admission-related conditions, and completed otherwise. It records that outcome without consulting settled delivery failures. (src/auto-reply/reply/dispatch-from-config.finalize.ts:499, 6a565393916d)
Failures are accounted for rather than merely logged: Delivery exceptions are converted into settlement outcomes; failed-before-send and failed-after-send counts are recorded. dispatchInboundMessage attaches the drained settled receipt to its result, but that receipt contains counts and visibility facts rather than provider code/message details. (src/auto-reply/reply/reply-dispatcher.ts:508, 6a565393916d)
Existing settlement owner: GitHub verifies fix(reply): report settled delivery outcomes once #124773 merged as eb38d5e. It established settled receipts and removed downstream reconstruction of delivery counts, providing the existing owner for any reporting repair. (src/auto-reply/reply/reply-dispatcher.ts, eb38d5e4863a)
Concrete table-limit trigger has a narrower merged fix: Current Feishu rendering checks the static-card table limit. GitHub verifies fix(feishu): fall back to post mode over table limit #136382 merged on September 6, implementing post-mode fallback for over-limit tables; this addresses the example trigger but not general agent-facing delivery-error reporting. (extensions/feishu/src/reply-dispatcher.ts:1320, 7e21eebac413)
Current recovery consumes settlement facts: Feishu's fallback predicate checks settled failed-before-send finals and empty eligible dispatches. Its error observer records failed final state, while recovery avoids intentional suppression and already-visible replies. (extensions/feishu/src/reply-delivery-result.ts:30, 6a565393916d)
Earlier candidate did not land: GitHub confirms fix(feishu): prevent silent replies after rejected card sends #122383 is closed with merged=false. Its supplied discussion and body describe a shared delivery-terminal/error contract and useful validation, but those claims cannot establish implementation on main.

Likely related people:

steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
joshavant: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.

Navigation Menu

Repository navigation

Bug: Feishu API errors silently swallowed, agent receives outcome=completed on failure #119862

Description

Steps to Reproduce

Expected Behavior

Actual Behavior

Root Cause

Suggested Fix

Impact

4 remaining items

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Bug: Feishu API errors silently swallowed, agent receives outcome=completed on failure #119862

Description

Description

Steps to Reproduce

Expected Behavior

Actual Behavior

Root Cause

Suggested Fix

Impact

Activity

clawsweeper commented on Aug 6, 2026

4 remaining items

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions