Greptile Summary

This PR fixes a UX gap where Discord users received no feedback when the channels.discord.inboundWorker.runTimeoutMS deadline expired while the model was still processing. The fix introduces an optional observer pattern on processDiscordMessage to surface three lifecycle events (onFinalReplyStart, onFinalReplyDelivered, onReplyPlanResolved) to the caller, which are then used in processDiscordInboundJob to decide whether a fallback timeout reply should be sent.

Key changes:

• inbound-worker.ts: On worker timeout, a "Discord inbound worker timed out." error reply is delivered via the existing deliverDiscordReply path, routed to the correct channel or auto-created thread. The fallback is suppressed if onFinalReplyStart or onFinalReplyDelivered has already fired.
• message-handler.process.ts: Adds the optional DiscordMessageProcessObserver interface and hooks (notifyFinalReplyStart is idempotent and called before each final-reply delivery await; onReplyPlanResolved is called right after the reply plan resolves, early enough to capture a just-created auto-thread ID).
• message-handler.queue.test.ts: Four new focused tests verify the happy path, suppression when the reply is complete, suppression when the reply is in flight, and auto-thread routing.

The implementation is clean, well-scoped, and the logic is correct. The rest field intentionally omitted from the timeout reply's deliverDiscordReply call is acceptable since token-based delivery is the fallback path and rest is an optional parameter. The fire-and-forget (void) dispatch of the timeout reply is appropriate because error handling is contained within sendDiscordInboundWorkerTimeoutReply and the timeout callback must be synchronous.

Confidence Score: 4/5

• This PR is safe to merge — it is a well-scoped, additive bug fix with no breaking changes to existing call sites.
• The logic is correct: the finalReplyStarted gate reliably prevents double-sends because notifyFinalReplyStart() is always called synchronously before any final-reply await, while the timeout fires as a macrotask and cannot interleave with in-progress synchronous code. The observer is optional, so no existing callers are affected. The four new tests cover the primary scenarios (basic fallback, already-delivered suppression, in-flight suppression, auto-thread routing). One point deducted for the absence of a test covering the case where onReplyPlanResolved is never called (i.e., timeout before resolveDiscordAutoThreadReplyPlan resolves), though the fallback to messageChannelId handles it correctly in production.
• No files require special attention.

_{Last reviewed commit: 41cae55}

Triage result

Quick read

• Intent valid: ✅ Yes
• Solves the right problem: ✅ Yes, mostly
• Refactor needed: 🔧 Superficial
• Human attention: 🟢 Not required
• Recommendation: 🏁 continue autonomously

Intent

This PR is trying to make Discord stop feeling frozen when the inbound worker times out. In plain English: if OpenClaw gives up on a long-running Discord request, the user should see an actual timeout message in Discord instead of silence.

Why

• The intention is good and user-facing. The timeout already happens; this PR is about making that failure visible instead of forcing people to infer it from logs.
• The core idea is right: reuse the normal Discord reply path so the timeout notice goes back to the same place the real reply would have gone, and suppress the fallback once final reply delivery has already started.
• This does not look like a fundamental redesign problem. The main issue is that the PR is stale against current main.
• The repo has since moved this Discord surface from src/discord/... to extensions/discord/..., and GitHub shows this PR as dirty / conflicting. So the work needs a straightforward port or rebase onto the current Discord extension files, not a human-level reframing of the feature.
• I do not think this needs product or architecture judgment before moving forward. It looks like an ordinary update-and-retest job.

AI review

• Status: ✅ Clear of remaining P0/P1 blockers
• Notes: This PR has already gone through AI review. The Codex review raised one ordering concern: if the timeout fallback send is fire-and-forget, a newer reply could appear before the older timeout notice. That was a valid comment, and the later commit changed the worker timeout path to await the fallback send before finishing the run. I do not see any remaining P0 or P1 AI findings on the PR as it stands.

CI/CD

• Status: ⏸️ Historical run was green, but the branch is now stale
• Notes: The historical CI run on this PR was green. But that is not enough to call it merge-ready today, because the branch is now conflicting with current main. The old CI result is a good sign for the original change, but it is stale as a landing signal.

Recommendation

🏁 continue autonomously

What I would do next is:

1. port this change onto the current extensions/discord/... files
2. rerun AI review on the updated PR head
3. rerun CI on the rebased branch

If that updated branch stays as scoped as this one, I would not send it back for human attention just because of the repo drift.

I rebased this fix locally onto current main, validated it, and published the updated branch as a replacement PR because this account cannot push to the original fork branch directly.

Replacement PR:
#53823

What changed in the replacement:

• ports the fix from the old src/discord/... surface onto the current extensions/discord/... files
• keeps the visible timeout reply behavior
• keeps created auto-thread routing for the fallback reply
• properly preserves queue ordering by making the worker timeout helper await async timeout cleanup before the next queued run starts

Validation run on the rebased branch:

• pnpm test -- extensions/discord/src/monitor/message-handler.queue.test.ts extensions/discord/src/monitor/message-handler.bot-self-filter.test.ts
• pnpm build

I had to recreate this on a branch I can actually update.

Replacement PR: #53823
#53823

That replacement keeps the same contributor-authored commits and author info on top of current main:

• 684ca2d fix(discord): notify user on discord when inbound worker times out.
• 80062f6 fix(discord): notify user on discord when inbound worker times out.
• e5c389d Discord: await timeout fallback reply

I do not have permission to close #40819 from this account, so the PR itself still has to be closed by someone with write access.