* fix(sms): adopt durable ingress drain with ack gated on MessageSid enqueue
Twilio inbound webhooks acked 200 then dispatched detached behind a 10-minute
in-memory replay guard; Twilio does not reliably retry inbound messages, so a
crash between ack and dispatch silently lost the SMS. The raw Twilio form now
enqueues durably (event_id = MessageSid, lane per sender) before the TwiML
200; dispatch, retry, dead-letter, and tombstones run through the core drain
with a startup + interval pump for restart recovery. Payload/account
validation moved to parse-at-dispatch and dead-letters as non-retryable. The
replay guard and its saturation 429 path are deleted; 24h/20k tombstones
strictly cover the old 10min/10k window.
Autoreview P1 (ambiguous non-adopted settlement) rejected with evidence:
bindIngressLifecycleToReplyOptions threads onAdopted/onDeferred/onAbandoned
into reply admission, so deferral and abandonment settle via core lifecycle
callbacks; normal non-adopted return = terminal local handling, matching the
Telegram reference mapping (skipped -> completed). Part of #109657 wave 1.
* fix(sms): keep ingress payload type internal
* fix(sms): preserve Twilio message SID aliases
* fix(sms): preserve ingress ordering and timestamps
* test(sms): satisfy type and lint gates
* fix(line): run post-ack webhook processing on its own admitted work root
LINE acks the webhook and dispatches event processing fire-and-forget on
the same async chain. The HTTP request admission that chain inherited is
released as soon as the route handler returns, and a released admission
refuses subordinate queue work - so every LINE inbound agent turn fails
with "GatewayDrainingError: Gateway is draining; new tasks are not
accepted" even though the gateway is healthy. DMs, group mentions, and
postbacks are all affected; the user-visible symptom is the bot replying
"Sorry, I encountered an error processing your message." to everything.
Add runDetachedWebhookWork to the plugin-sdk webhook-request-guards
surface (a thin wrapper over the gateway independent-root continuation,
the same shape core uses in gateway/server/hooks.ts) and route all three
LINE ack-first dispatch sites through it: the gateway monitor handler
(the live path), and the createLineNodeWebhookHandler / Express
middleware handlers (public webhook building blocks an embedder can
register under the gateway). #65375 unified these three into one ack-first
pattern; keeping the detach consistent avoids re-introducing the same
latent defect in the two that are not on the live gateway path today.
The continuation is reserved synchronously while the request is still
admitted, so the detached processing stays accepted and a real restart
drain can wait for it instead of stranding it mid-turn.
Tests pin every layer: the guards suite proves detached post-ack work is
admitted after the request admission is released (and that the inherited
chain without the helper is refused); the monitor lifecycle suite and the
webhook-node suite assert each dispatch site goes through the detached
root. Red/green verified: reverting any dispatch fails its test.
* fix(plugin-sdk): account for runDetachedWebhookWork in public surface budget
* fix(channels): track detached webhook processing
Co-authored-by: 許元豪 <146086744+edenfunf@users.noreply.github.com>
* docs: refresh generated docs map
* chore(plugin-sdk): refresh API baseline
* fix(webhooks): preserve post-ack ordering
* test(plugin-sdk): satisfy detached work lint
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
Vincent Koc