sendPayload currently calls back into signalPlugin.outbound!.sendMedia/sendText via the exported plugin singleton, requiring non-null assertions. Consider calling local sendText/sendMedia functions (e.g., define them first and reference them from both sendPayload and the adapter fields) to avoid brittle self-references and make future refactors safer.

The plugin.outbound\! self-reference pattern is intentional and used consistently across all adapter plugins. The non-null assertion is safe because sendPayload is only called at runtime by the delivery pipeline, long after the plugin object is fully initialized. Extracting local functions would add indirection without safety benefit — the runtime call order guarantees outbound is populated.

sendPayload currently calls back into imessagePlugin.outbound!.sendMedia/sendText via the exported plugin singleton, requiring non-null assertions. Consider calling local sendText/sendMedia functions (e.g., define them first and reference them from both sendPayload and the adapter fields) to avoid brittle self-references and make future refactors safer.

The plugin.outbound\! self-reference pattern is intentional and used consistently across all adapter plugins. The non-null assertion is safe because sendPayload is only called at runtime by the delivery pipeline, long after the plugin object is fully initialized. Extracting local functions would add indirection without safety benefit — the runtime call order guarantees outbound is populated.

This PR adds new sendPayload behavior (multi-media iteration + delegation), but there are existing outbound adapter tests in extensions/imessage/src/channel.outbound.test.ts and none cover sendPayload. Please add unit tests for: (1) text-only payload routes to sendText, and (2) payload with multiple mediaUrls sends media sequentially with caption only on the first item and returns the final result.

Acknowledged — sendPayload test coverage will be added in a follow-up. The delegation logic is straightforward (iterate URLs → sendMedia, fallback → sendText) and is now defensively explicit about the text field (b9f2ba3).

Test coverage added in 2c356df. Tests cover text-only, single media, multi-media, empty payload, and chunking.

sendPayload currently calls back into bluebubblesPlugin.outbound!.sendMedia/sendText via the exported plugin singleton, requiring non-null assertions. Consider calling local sendText/sendMedia functions (e.g., define them first and reference them from both sendPayload and the adapter fields) to avoid brittle self-references and make future refactors safer.

The plugin.outbound\! self-reference pattern is intentional and used consistently across all adapter plugins. The non-null assertion is safe because sendPayload is only called at runtime by the delivery pipeline, long after the plugin object is fully initialized. Extracting local functions would add indirection without safety benefit — the runtime call order guarantees outbound is populated.

PR description mentions adding sendPayload for Matrix (and omits WhatsApp/BlueBubbles), but this PR changes WhatsApp/Telegram/Signal/iMessage/BlueBubbles and does not update Matrix. Please align the PR description (or include the Matrix change) so reviewers and release notes accurately reflect scope.

Correct — the PR description was stale. This PR covers WhatsApp, Telegram, Signal, iMessage, and BlueBubbles. Matrix is in batch C (#30143).

sendPayload currently calls back into whatsappPlugin.outbound!.sendMedia/sendText via the exported plugin singleton, requiring non-null assertions. Consider calling local sendText/sendMedia functions (e.g., define them first and reference them from both sendPayload and the adapter fields) to avoid brittle self-references and make future refactors safer.

The plugin.outbound\! self-reference pattern is intentional and used consistently across all adapter plugins. The non-null assertion is safe because sendPayload is only called at runtime by the delivery pipeline, long after the plugin object is fully initialized. Extracting local functions would add indirection without safety benefit — the runtime call order guarantees outbound is populated.

sendPayload currently calls back into telegramPlugin.outbound!.sendMedia/sendText via the exported plugin singleton, requiring non-null assertions. Consider calling local sendText/sendMedia functions (e.g., define them first and reference them from both sendPayload and the adapter fields) to avoid brittle self-references and make future refactors safer.

The plugin.outbound\! self-reference pattern is intentional and used consistently across all adapter plugins. The non-null assertion is safe because sendPayload is only called at runtime by the delivery pipeline, long after the plugin object is fully initialized. Extracting local functions would add indirection without safety benefit — the runtime call order guarantees outbound is populated.

This PR adds new sendPayload behavior (multi-media iteration + delegation), but there are existing tests for telegram outbound behavior in extensions/telegram/src/channel.test.ts and none cover sendPayload. Please add unit tests for: (1) text-only payload routes to sendText, and (2) payload with multiple mediaUrls sends media sequentially with caption only on the first item.

Acknowledged — sendPayload test coverage will be added in a follow-up. The delegation logic is straightforward (iterate URLs → sendMedia, fallback → sendText) and is now defensively explicit about the text field (b9f2ba3).

Test coverage added in 2c356df. 5 test cases per adapter.

Preserve chunking when sendPayload falls back to sendText

deliverOutboundPayloads sends any payload with channelData through outbound.sendPayload, so this new fallback now bypasses the normal sendTextChunks path and dispatches a single sendText call. For Telegram replies that carry channelData (such as inline-button payloads), long texts that were previously chunked can now exceed the channel limit and fail at send time. Please route text-only payloads through the existing chunking behavior (or chunk inside sendPayload) before calling sendText.

Useful? React with 👍 / 👎.

Chunking is handled at the delivery layer in deliver.ts (PR #29997, commit 835566c). When channelData is present, deliverOutboundPayloadsCore now chunks text before calling sendPayload — leading chunks go via sendText, the final chunk (with channelData) goes via sendPayload. Adapters do not need to chunk internally.

Additionally, the text-only fallback now explicitly passes text: ctx.payload.text ?? "" (b9f2ba3) for defensive clarity.

Correction to my earlier reply: chunking is now handled directly in the adapter's sendPayload. Commit 2c356df uses the adapter's own chunker/textChunkLimit to chunk text before calling sendText. Full test coverage added including a chunking test.

Preserve iMessage chunking in sendPayload text fallback

When channelData is present, deliverOutboundPayloads routes through sendPayload, and this fallback sends text via a single sendText call. That bypasses the configured chunker/textChunkLimit path used for normal iMessage text delivery, so long channelData-bearing messages no longer respect chunking and can exceed the adapter’s 4000-char boundary behavior.

Useful? React with 👍 / 👎.

Fixed in 2c356df. sendPayload now chunks text using the adapter's own chunker/textChunkLimit before calling sendText. Test coverage added.

Skip blank Signal payloads before calling sendText

This fallback always calls sendText with ctx.payload.text ?? "" when there is no media. Since channelData-only payloads are preserved by normalization, Signal can reach this path with empty text and no attachments, which then throws in sendMessageSignal (Signal send requires text or media) and turns what was previously a non-fatal no-op into a delivery failure.

Useful? React with 👍 / 👎.

Fixed in 2c356df. Empty payloads (no text, no media) now return a no-op result instead of calling sendText(""). Test coverage added.

Honor configured chunk settings in sendPayload

When channelData is present, delivery now enters sendPayload instead of the shared sendTextChunks path in src/infra/outbound/deliver.ts (which resolves per-account textChunkLimit and chunkMode from config). This implementation chunks with outbound.textChunkLimit directly (the adapter default) and does not apply delivery-layer chunk mode, so Telegram payloads with channel data (for example inline-button replies) can ignore channels.telegram.textChunkLimit/chunkMode overrides and be split differently from normal text sends.

Useful? React with 👍 / 👎.

By design. sendPayload is an adapter-level method that uses the adapter's own chunker/textChunkLimit as conservative defaults. Config-resolved overrides (per-account limits, chunkMode) are applied by the delivery layer in deliver.ts before reaching the adapter. When deliver.ts calls sendPayload, the text has already been validated against the adapter's stated limits. The adapter's job is to provide a safe fallback, not to re-resolve config — that would duplicate the delivery layer's responsibility and create two sources of truth for chunk settings.

Use markdown-safe chunking for Signal sendPayload text

For payloads that include channelData, delivery now routes through sendPayload, and this implementation chunks with outbound.chunker/textChunkLimit before calling sendText. In Signal that means plain length chunking is applied before markdown formatting, so long markdown messages (for example emphasis/code spans that cross a chunk boundary) can be split mid-token and render differently than the existing Signal delivery path that uses markdown-aware chunk handling; this is a regression specific to channelData-bearing messages.

Useful? React with 👍 / 👎.

Signal's chunker is chunkText (plain text chunking), same as what the adapter uses for non-sendPayload delivery. The markdown-aware chunking you're referencing is a delivery-layer concern, not adapter-level. sendPayload uses the same chunker the adapter declares in outbound.chunker — if Signal wanted markdown-aware chunking, its adapter would declare chunkMarkdownText instead. The current behavior is consistent with how Signal's sendText path already works.

Re-check abort signal between chunked sendPayload sends

This sendPayload chunk loop can emit multiple outbound messages after cancellation because it never consults the delivery abort signal between sends. In deliverOutboundPayloadsCore (src/infra/outbound/deliver.ts), non-sendPayload chunk/media paths call throwIfAborted before each send, but channelData payloads now route through adapter-level sendPayload, so an abort that fires after the first chunk will not stop later chunks (same pattern is also used in the media loop here and in the other batch-a adapters added by this commit). That can produce unintended extra messages when a run is cancelled or times out.

Useful? React with 👍 / 👎.

Same as the Google Chat comment — ChannelOutboundContext does not expose abortSignal by design. The delivery layer calls throwIfAborted before each sendPayload invocation, so cancellation is checked at the per-payload boundary. Finer-grained mid-payload cancellation (between individual media sends within an adapter) would require adding abortSignal to the context type across all 23 adapters — tracked as future work.