Propagate outbox ack failures to recovery loop

ackDelivery swallows all SQLite update errors and returns normally, so recoverPendingDeliveries can count an entry as recovered even when the row never transitions to delivered. If the UPDATE message_outbox ... status='delivered' write fails (for example SQLITE_BUSY/I/O errors), the row remains queued and will be replayed on later worker passes, causing duplicate outbound sends and incorrect turn lifecycle state.

Useful? React with 👍 / 👎.

ackDelivery has no try/catch — SQLite errors propagate to the caller. The .catch(() => {}) at call sites in deliver.ts is intentional best-effort: delivery already succeeded at that point, so the ack is bookkeeping. If the ack write fails, the entry stays queued and the recovery worker picks it up on the next pass — which is correct, since re-delivery of an already-delivered message is idempotent at the channel level (the outbox dedup key prevents double-send on most channels, and for those without dedup, a re-delivered reply is preferable to a lost one).

Surface failDelivery write errors to enforce backoff

failDelivery also suppresses database write failures, which means retry metadata (attempt_count, last_attempt_at, next_attempt_at) may never be persisted after a failed send. In that case the entry can stay effectively queued without backoff progression, so the recovery worker keeps retrying it as if it were fresh, creating a tight retry loop and repeated provider calls instead of controlled retry/terminalization behavior.

Useful? React with 👍 / 👎.

Same pattern: failDelivery has no try/catch and errors propagate. The .catch(() => {}) in deliver.ts is intentional — at that point the send already failed and the primary error is thrown to the caller. If the DB write fails, the entry stays queued without backoff progression, but this is self-correcting: the recovery worker will retry it, and on success the ack will stick. The tight retry loop concern is bounded by MAX_RETRIES (5) — the attempt count is incremented in the same UPDATE statement, so terminal state is still reached. In practice, SQLite write failures are transient (SQLITE_BUSY under contention) and resolve on the next pass.

Apply turn pass limit after filtering skipped turns

runTurnPass caps the query result with .slice(0, maxTurnsPerPass) before it skips active turns and turns that still have queued outbox rows. Because listRecoverableTurns is ordered by oldest accepted_at, a backlog of old delivery_pending/active turns can permanently occupy the first N slots, so later orphaned turns are never replayed in this worker cycle. This starves recovery under load and can leave recoverable turns stuck until the head-of-line set clears.

Useful? React with 👍 / 👎.

Fixed in 541f3ee: runTurnPass now applies maxTurnsPerPass after filtering out active and already-finalized turns, so the cap counts only turns that are actually replayed. Previously, skipped turns consumed slots in the pre-filtered .slice(), starving later recoverable turns under load.

Restrict v2 payload fast-path to true native sendFinal adapters

This branch treats any adapter with normalized.contract === "v2" as safe for sendPayload, but in this commit several adapters are marked outboundContract: "v2" while still relying on inferred sendFinal from sendText/sendMedia (for example Slack/Discord/WhatsApp). When payload.channelData is present, delivery now bypasses chunking and multi-media fan-out and sends through that inferred single-message path, which can cause oversized message failures and silently drop extra attachments.

Useful? React with 👍 / 👎.

This is the same issue as the P1 on #29148 (thread 6). Fixed in the same commit (377a635): createPluginHandler now preserves sendPayload for v1 adapters that implement it natively, while still blocking inferred sendFinal from the fast path. Channels like Slack/Discord/WhatsApp that use sendText/sendMedia without native sendPayload are unaffected — they declare outboundContract: "v2" and provide native sendFinal, so the isNativeV2 path correctly handles them.

Skip delivery recovery for aborted turns

The pending-outbox query only filters message_outbox status/time, so entries linked to turns that were explicitly aborted are still replayed by recoverPendingDeliveries. After /stop calls abortTurnsForSession(...), any already-enqueued row (for example a transient failed_retryable send) remains eligible here and can still be delivered to the user, which violates abort semantics and surfaces stale replies after cancellation.

Useful? React with 👍 / 👎.

Fixed in e6899d7. abortTurnsForSession now includes a second UPDATE after marking turns as aborted:

UPDATE message_outbox
  SET status='failed_terminal',
      error_class='terminal',
      terminal_reason='turn_aborted',
      completed_at=?
WHERE turn_id IN (
  SELECT id FROM message_turns WHERE session_key=? AND status='aborted'
)
  AND status IN ('queued','failed_retryable')

This ensures recoverPendingDeliveries won't replay sends for turns that were aborted (e.g. session teardown). The outbox entries are marked terminal in the same try/catch block as the turn abort, so they're cleaned up atomically with the turn status change.

Bypass inbound dedupe when replaying a persisted turn

Recovered turns are replayed through dispatchResumedTurn, but this path still runs dispatchReplyFromConfig's duplicate-inbound gate (shouldSkipDuplicateInbound) using the original MessageSid. If a turn is marked failed_retryable in-process (for example, final routing failed) and retried within the dedupe TTL, the replay is skipped as a duplicate; then dispatchInboundMessageInternal sees no outbox rows and finalizes the turn as delivered, so the failed reply is silently dropped and no further recovery happens.

Useful? React with 👍 / 👎.

Gate fail-open delivered status on actual final send success

This fail-open branch marks a turn delivered whenever attemptedFinal > 0 && queuedFinal, but queuedFinal only means sendFinalReply accepted the payload into the dispatcher queue, not that delivery succeeded. If outbox persistence fails (enqueueDelivery returns null) and the provider send later fails, no outbox row exists and this branch still terminalizes as delivered, which suppresses retry/recovery for a user-visible missing final reply.

Useful? React with 👍 / 👎.