Summary

Describe the problem and fix in 2–5 bullets:

• Problem: Feishu reply sends fail hard when parent message is withdrawn/deleted (230011 / 231003), causing replies to be dropped.
• Why it matters: users receive no response even though agent output was produced.
• What changed: reply sends for post/interactive messages now detect withdrawn/not-found reply target errors and fall back to normal message.create send.
• What did NOT change (scope boundary): generic retry/backoff policy and typing-indicator behavior were not changed.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Feishu: reply silently dropped when target message is withdrawn/deleted #27103
• Related Feishu: typing indicator keepalive causes repeated push notifications #28660

User-visible / Behavior Changes

• If reply target message has been withdrawn/deleted, Feishu replies now fall back to a normal send so the user still receives the response.

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node.js + pnpm workspace
• Model/provider: N/A
• Integration/channel (if any): Feishu
• Relevant config (redacted): N/A

Steps

1. Simulate Feishu reply API returning withdrawn/not-found response codes.
2. Call Feishu send path with replyToMessageId.
3. Verify fallback create send is attempted.
4. Run tests:
   • pnpm vitest extensions/feishu/src/send.reply-fallback.test.ts --run
   • pnpm check

Expected

• Withdrawn/not-found reply target should not drop response; send should fall back to normal create API.

Actual

• Before fix: reply path threw and stopped.
• After fix: reply path falls back to create and returns successful send result.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • post reply fallback on 230011.
  • card reply fallback on 231003.
  • non-withdrawn reply failures still throw (no over-broad fallback).
• Edge cases checked:
  • fallback uses same receive target and msg_type payload.
• What you did not verify:
  • Live Feishu API calls in a real tenant.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly:
  • Revert this PR commit.
• Files/config to restore:
  • extensions/feishu/src/send.ts
  • extensions/feishu/src/send.reply-fallback.test.ts
• Known bad symptoms reviewers should watch for:
  • unexpected fallback sends on unrelated reply errors.

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

• Risk:
  • Message-based heuristic could match unrelated error messages in non-English locales.
  • Mitigation:
    • Primary trigger uses known Feishu error codes (230011, 231003); message-text check is secondary.