Emit the established OpenClaw durable-delivery response marker only after an authenticated, non-empty LINE webhook event has been persisted. Verify the production gateway route with signed real HTTP requests covering verification, delayed admission, invalid signatures, and storage failures.
Co-authored-by: 許元豪 <146086744+edenfunf@users.noreply.github.com>
* fix(line): preserve webhook object error details
* fix(line): preserve structured errors on the live webhook route
* test(line): provide the complete typed runtime to webhook proof
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(line): deliver rich replies on the reply token instead of the push quota
A reply token carries five messages for free, while push spends the account's
monthly quota. Text rode the token and the rich/media bubbles were pushed after
it, so an extracted table vanished with a 429 once that quota was gone. Bundle
both onto the token and push only the overflow.
Quick replies now ride the trailing message instead of the last reply-token
slot: LINE hides them as soon as a newer message arrives, so an overflowing
batch pushed its bubbles after the buttons and wiped them.
* refactor(line): unify auto-reply batching
* test(line): remove unused token fixture
* refactor(line): delete legacy reply chunk path
* fix(line): recover text from rejected mixed batches
* test(line): split auto-reply recovery coverage
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* 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