Recover non-final outbox rows to avoid stuck turns

The recovery query now skips rows where dispatch_kind is tool/block, but turn state still treats those rows as active/failing (getOutboxStatusForTurn and runTurnPass count all queued/failed rows). If a tool/block send is left queued or failed_retryable (for example after a transient send error or crash), that row is never retried, so the turn stays delivery_pending and can later be marked failed on expiry even when the final reply was otherwise successful. This creates persistent stuck/failed turns after restart/error scenarios.

Useful? React with 👍 / 👎.

Non-final rows are excluded from turn health checks by the dispatch_kind SQL filter (added in the write-ahead-recovery PR). The fix in #30009 now terminates orphaned non-final rows during recovery, ensuring they're cleaned up and don't cause stuck turns.

Don't fail routed ACP turns via dispatcher send count

This success check assumes final replies are sent through the local dispatcher, but ACP cross-surface routing sends final payloads via routeReply (see tryDispatchAcpReply in src/auto-reply/reply/dispatch-acp.ts) and never increments successfulSends. In that case attemptedFinal/queuedFinal can both be true while successfulSends remains 0, so this branch records a recovery failure for turns that were actually delivered, causing unnecessary retries and eventual terminal turn failures.

Useful? React with 👍 / 👎.

Same concern as #30011 comment — fixed there with the outbox-based fail-open change. This PR inherits the fix from the turn-tracking base branch.

Base turn success on final-dispatch rows only

This branch marks a turn as delivered whenever any outbox row is delivered, but getOutboxStatusForTurn aggregates tool/block/final rows together. If tool or block messages succeed and the final reply fails to queue/send (attemptedFinal > 0, queuedFinal = false), the turn is still finalized as delivered here, so recovery never retries the missing final response. That causes user-visible dropped final replies after partial-success turns.

Useful? React with 👍 / 👎.

Fixed — same fix as #30011. getOutboxStatusForTurn now accepts { finalOnly: true } which filters to final-dispatch rows only. Both outbox status checks in dispatch.ts and the turn pass now use this option, so tool/block sends no longer cause premature turn finalization.

Link ACP final attempts to turn outbox records

Fresh evidence in this commit: tryDispatchAcpReply now increments attemptedFinal, but ACP-routed sends still call routeReply without a turnId, so the final outbox rows are not associated with the turn. In dispatchInboundMessageInternal, the new finalization logic relies on turn-scoped outbox status (and otherwise falls back to dispatcher send counters), which means cross-surface ACP replies can be marked as recovery failures and retried/failed even when delivery succeeded.

Useful? React with 👍 / 👎.

Same fix as #30011 — ACP final deliveries now correctly linked to their turn via turnId: params.ctx.MessageTurnId in the routeReply() call. Fix landed in b6b842c on lifecycle/turn-tracking.

ackDelivery() swallows all DB errors and leaves the row in a retryable state; the recovery worker will then re-send the message. That creates guaranteed duplicate deliveries if the UPDATE fails (and the comment assumes provider idempotency that isn't enforced here). Consider making ack/fail writes more reliable (e.g. retry/propagate, or at least elevate to warn/error and prevent resend on bookkeeping-only failures).

importLegacyFileQueue() sets next_attempt_at to lastAttemptAt/enqueuedAt without applying the backoff schedule. Because loadPendingDeliveries filters on next_attempt_at, this can cause high-backoff legacy retries to be scanned every tick and then deferred in-memory. Consider computing next_attempt_at as (baseAttemptAt + computeBackoffMs(retryCount)) during import so SQLite can filter deferred rows efficiently.

When the INSERT OR IGNORE is ignored due to an existing dedupe_key, acceptTurn() returns accepted=false but still returns a newly-generated id that does not correspond to any stored turn row. That makes logs/metrics misleading and prevents callers from referencing the existing turn. Consider fetching and returning the existing turn id (e.g. SELECT id WHERE dedupe_key=?) when changes() is 0.

This comment says the outbox worker defers fresh entries for 5s, but the current recovery eligibility is driven by next_attempt_at/startupCutoff (and enqueueDelivery writes next_attempt_at=now). Please update the comment to reflect the actual deferral mechanism so the test remains self-explanatory.

ensureLifecycleSchema() drops and recreates indexes unconditionally. On a non-trivial DB this can be expensive and can briefly lock the database on every gateway start. Consider using a schema version/migration (or only dropping when the existing index definition differs) instead of always running DROP INDEX.

Recover post-start rows missing attempt metadata

This startup-cutoff predicate permanently excludes rows created after boot unless attempt_count > 0 or last_attempt_at is set. In the current flow, ackDelivery/failDelivery intentionally swallow DB write errors, so a send can succeed or fail while the outbox row remains queued with attempt_count=0 and no last_attempt_at; with startMessageLifecycleWorkers always passing startupCutoff, that row is never retried until a full restart. For turn-linked deliveries this can leave turns stuck in delivery_pending and later marked stale/failed even though delivery already happened or should have been retried.

Useful? React with 👍 / 👎.

Propagate dispatch kind when routing turn-linked payloads

routeReply now attaches turnId for all routed sends, including tool/block payloads emitted via dispatch-from-config and ACP routing, but these rows are still enqueued without a dispatch_kind and therefore look like final sends to lifecycle queries that treat dispatch_kind IS NULL as final-only. In cross-surface streaming/tool scenarios, those non-final rows can be replayed by recovery and can also make turn finalization read as delivered/failed based on tool/block outcomes instead of the actual final reply. Please pass the reply kind through the routing path so outbox rows are tagged and excluded from final-only turn health checks.

Useful? React with 👍 / 👎.