Preserve chunking/media fan-out for inferred sendFinal adapters

createPluginHandler now enables sendPayload whenever outbound.sendFinal exists, but normalizeChannelOutboundAdapter synthesizes sendFinal for plain sendText/sendMedia adapters too. That means any payload with channelData now takes the sendPayload fast path and skips the normal chunking and per-media loop in deliverOutboundPayloadsCore; with the inferred implementation this can drop all but the first mediaUrl (and bypass text chunking), so channelData messages with attachments or long text can be delivered incorrectly.

Useful? React with 👍 / 👎.

Fixed in aabc291: sendPayload is now only set when normalized.contract === "v2" (native sendFinal). Inferred sendFinal from v1 sendText/sendMedia adapters no longer takes the sendPayload fast path, so channelData payloads continue through the normal chunking and per-media fan-out loop.

Already addressed in aabc291, and further refined in 377a635 which also preserves the sendPayload path for v1 adapters with native sendPayload (e.g. LINE).

Preserve sendPayload path for legacy adapters

Restricting sendPayload to normalized.contract === "v2" drops channel-data delivery for existing v1 adapters that still implement sendPayload (for example extensions/line/src/channel.ts handles quick replies/templates via payload.channelData but does not declare outboundContract: "v2"). In that configuration, deliverOutboundPayloadsCore no longer calls the adapter’s sendPayload and falls back to sendText/sendMedia, which silently strips LINE-specific rich message metadata.

Useful? React with 👍 / 👎.

Good catch. Fixed in 377a635: createPluginHandler now also exposes sendPayload when the original v1 adapter implements it natively (e.g. LINE). The isNativeV2 guard still prevents inferred sendFinal from taking the fast path, but v1 adapters with their own sendPayload (like LINE's channelData handler) are passed through directly via hasNativeSendPayload.

Preserve dispatch kind when queuing dispatcher payloads

These rows enqueue every normalized payload without recording whether it was a tool, block, or final send, but crash recovery replays all queued rows through deliverOutboundPayloads (see src/gateway/server-message-lifecycle.ts). That means channels that intentionally suppress non-final sends in their live dispatcher (for example src/web/auto-reply/monitor/process-message.ts returns early when info.kind !== "final") can leak those suppressed payloads after a crash if the process dies between enqueueDelivery and ackDelivery; on restart, recovery will treat them as normal outbound messages and send them to users.

Useful? React with 👍 / 👎.

Fixed in 46581bc. enqueueDelivery now accepts and stores dispatchKind ("tool" / "block" / "final") in the outbox payload JSON. The reply dispatcher passes kind through at the call site.

During recoverPendingDeliveries, after loading pending entries, non-final entries (those with dispatchKind set and not "final") are marked failed_terminal with terminal_reason='non_final_recovery_skip' and excluded from recovery. This is safe because the turn recovery worker replays the entire turn, regenerating tool/block outputs — recovering them from the outbox would bypass channel-specific kind filtering (e.g. web channel suppresses non-final sends in the live path).

Entries without dispatchKind (legacy rows, or entries from deliverOutboundPayloads) are treated as final and recovered normally.

Keep text/media adapters on v1 until sendFinal is native

Fresh evidence in this commit is that core adapters like Slack are now marked outboundContract: "v2" even though they only implement sendText/sendMedia. That makes createPluginHandler treat them as native v2 and route any channelData payload through sendPayload/sendFinal; for inferred sendFinal, compat.ts only forwards the first media URL, so multi-media and chunked deliveries can be truncated when channelData is present (the fast path is taken whenever effectivePayload.channelData exists). Keep these adapters on v1 until they provide a real sendFinal that preserves fan-out/chunk semantics.

Useful? React with 👍 / 👎.

Propagate ackDelivery failures instead of swallowing them

ackDelivery now catches and suppresses every DB error, but recovery still counts the entry as recovered immediately afterward. If the SQLite update fails (for example SQLITE_BUSY during concurrent access), the row remains pending and will be replayed on later worker ticks, producing duplicate outbound sends while logs report success. Letting this error propagate (or returning an explicit failure) would allow recovery to treat it as a failed attempt instead of silently requeueing duplicates.

Useful? React with 👍 / 👎.

Queue the effective thread target for crash recovery

In resolveDeliveryQueueContext, the queued threadId is copied only from ctx.MessageThreadId, but some channels compute the actual reply thread at send time; for example Slack with replyToMode: "first" resolves the first reply thread via replyPlan.nextThreadTs() in src/slack/monitor/message-handler/dispatch.ts while MessageThreadId remains unset for top-level messages. If the process crashes after enqueue and before send, recovery replays through deliverOutboundPayloads without a thread id and the recovered reply is posted to the channel root instead of the intended thread.

Useful? React with 👍 / 👎.