OpenClaw Main Makes Partial Channel Delivery and Watchdog Failures Visible

OpenClaw has merged a cluster of channel-delivery fixes for two dangerous forms of false simplicity: a multi-part send could partly succeed while receipts or errors hid that fact, and a watchdog’s own error callback could throw hard enough to terminate the Gateway or leak an unhandled rejection.

The affected merged paths include Telegram, Zalo, ZaloUser and the shared channel watchdog. All are on main; operators should verify a containing build and stage failure boundaries rather than testing only successful one-part messages.

Partial delivery is neither success nor total failure

A reply containing media, captions, text chunks or attachments can produce several physical provider messages. If part one succeeds and part two fails, the operator needs both facts:

• which provider messages were accepted; and
• the original error that stopped the remaining delivery.

PR #117863 fixes Telegram receipts when a media caption must continue in follow-up text messages. The merged record preserves the first media message, returns ordered physical parts with message IDs and keeps the historical final-message identity for compatibility.

PRs #117864 and #117860 stop Zalo and ZaloUser paths from swallowing text or attachment failures. They retain accepted provider IDs and ordered partial receipts while allowing the authoritative dispatcher to report the failure.

Without that distinction, an automated retry may duplicate the parts recipients already saw.

Correlation entries must be consumed once

PR #117812 fixes a Telegram inbound-delivery correlation that could remain live until turn teardown. A second matching outbound send could invoke the marker again, and a throwing marker could leave it available for further reuse.

The corrected lifecycle consumes the correlation at its authoritative boundary. Upstream also consolidates elapsed-time and error-result probe handling for Twitch and Zalo, reducing drift between adapters.

A watchdog failure must not become a Gateway failure

PR #117652 reports that a transport-timeout callback or runtime error reporter could throw or reject from the watchdog timer, terminating the Gateway process or leaking an unhandled rejection.

The shared watchdog now owns the timer boundary: disarm first, report safely and contain failures from the reporting path. A monitoring callback is supposed to describe a transport fault, not amplify it into a process outage.

Acceptance matrix

Use synthetic payloads and disposable recipients:

Do not induce provider failures in customer conversations. Partial sends are recipient-visible by definition.

Operational changes

After adopting the fix:

• store ordered physical part receipts, not only one final message ID;
• distinguish not sent, partially sent and fully sent;
• retain the provider’s original error alongside accepted IDs;
• make retries content- and part-aware;
• alert if the watchdog itself cannot report; and
• verify the process remains healthy after reporter failure.

Interpretation: observability code and receipt aggregation are part of delivery correctness. If either lies, retry logic can create more damage than the original channel fault.

Evidence and limits

The official GitHub merged-PR and commit records supplied by the collector establish the reported failures and landed behavior. Direct GitHub extraction returned HTTP 403. Telegram and watchdog records carried sufficient-proof labels; the collected Zalo records still requested more proof. OpenClaw Academy did not send live provider messages or intentionally crash a production reporter.

Bottom line

A multi-part reply needs an accounting ledger, not one boolean. Stage a containing build by forcing failure after the first accepted part, prove every accepted provider ID survives, and confirm that both callback and watchdog failures remain contained instead of taking the Gateway with them.