[irresi]

What this fixes

MessageDeduplicator.is_duplicate() marks a message seen at check time, before processing finishes. WeCom acks a callback only via the reply frame and redelivers the same msgid on silence (#47573), so any failure between the mark and a completed run left a stale claim that swallowed every redelivery for the dedup TTL (300s) — silent message loss with only a DEBUG trace.

Fixes #62860.

How the claim lifecycle works now

A claim is released exactly when the message was NOT processed, and kept when it was:

• Synchronous intake failures (_on_message): release and re-raise.
• Batched dispatch (_flush_text_batch): the dispatch is wrapped in asyncio.shield — a supersede-cancel from a newer chunk can land before gateway acceptance (dropping the popped batch) or after it (double-processing on redelivery if released); letting the in-flight dispatch complete removes both cases. A shielded dispatch that still fails synchronously releases its claims via a done-callback.
• Background pipeline (the normal path — handle_message returns after scheduling _process_message_background): a new additive on_handler_failure lifecycle hook in base fires only when the message handler raised or was unexpectedly cancelled before completing, gated by a handler_completed flag. ProcessingOutcome.FAILURE alone is a delivery heuristic (a failed reply send, or an image-only reply that never records delivery, both classify FAILURE after a fully completed run) — releasing on it would re-run completed turns and duplicate tool side effects. The busy-session inline dispatch paths (bypass commands, clarify text-intercept) swallow handler exceptions by design; they now report through the same hook, so a failed /approve or clarify answer no longer keeps its claim while the agent stays blocked.
• Kept deliberately: completed turns with failed delivery, expected cancellations (/stop, session reset), and policy-blocked messages.

Claim ids ride MessageEvent.metadata["dedup_msg_ids"]; base's event merges (merge_pending_message_event, _queue_text_debounce) now preserve their union, since a dropped id stayed claimed forever after a failure. The key is unprefixed because base owns its merge semantics (_merge_dedup_claim_ids) — it is shared claim infrastructure, not adapter-private state.

Scope boundary

WeCom-only adoption by design. DingTalk's stream handler acks STATUS_OK before processing, so it never redelivers on later failure — a release there would be dead code. Other adapters sharing the helper (google_chat is at-least-once Pub/Sub, slack redelivers on Socket-Mode reconnects per its own comments) have the same mark-before-success shape and can adopt remove() + on_handler_failure in follow-ups; the base hook and merge preservation shipped here are what make that adoption one method per adapter.

Tests

tests/gateway/test_wecom_dedup_redelivery.py exercises the real dispatch lifecycle (set_message_handler + background tasks, no handle_message mock where the contract depends on base):

• synchronous intake failure → redelivery reprocessed; success → duplicate suppressed
• background handler failure → released via the hook; delivery failure after a completed handler → claim kept (redelivery must not re-run the turn)
• busy-session inline bypass failure (real /status on an occupied session) → released
• supersede-cancel → shielded dispatch completes; neither loss nor duplicate
• failed merged flush → head and appended chunk claims released independently (mutation-tested: a head-only release regression fails the suite)

pytest across the wecom/batching/dedup/base-session neighborhood: 157 passed, 1 pre-existing environmental failure (TestWeComZombieSessionFix, reproduces identically without these commits — missing optional aiohttp in the minimal dev env). ruff clean; ty diagnostics net −1 vs the previous head (macOS 15, Python 3.12; behavior is platform-independent).

[teknium1]

Thanks for tracing the stale dedup claim through the WeCom callback path. The pre-dispatch failure case is real on current main: plugins/platforms/wecom/adapter.py:499-500 marks the ID before parsing and dispatch.

Problems

• The new try blocks do not cover the normal agent-processing failure path. gateway/platforms/base.py:4779 makes handle_message() schedule _process_message_background() and return; the real _message_handler runs in that background task at gateway/platforms/base.py:4855-4859, whose failures are handled internally at gateway/platforms/base.py:5203-5231. Consequently, the new catches do not release a WeCom claim when that normal background path fails. The added tests mock handle_message, so they do not exercise this lifecycle.

Suggested changes

• Carry the WeCom claim to an appropriate processing-completion failure/cancellation path and add a regression test using the real background dispatch lifecycle.

Automated hermes-sweeper review.

[teknium1]

handle_message() normally returns after scheduling _process_message_background() (gateway/platforms/base.py:4779); actual handler failures are caught inside that background task (gateway/platforms/base.py:5203-5231). This catch therefore misses the normal agent-processing failure that can leave the claim stale. Please wire the release to the relevant completion/failure path and test the real lifecycle rather than a mocked handle_message exception.