Summary

When using Synology Chat Outgoing Webhook with OpenClaw's synology-chat extension, the chat UI can remain stuck on "Processing..." even though the bot pipeline is otherwise working.

After long debugging, the root cause is in the webhook handler contract:

• inbound handler only reliably reads application/x-www-form-urlencoded
• required fields are hard-coded as token, user_id, text from body
• handler responds with { "text": "Processing..." }

In real Synology deployments, outgoing payloads can differ (JSON bodies, alias field names, token in query/header), which leads to field extraction failure or permanent Processing state in UI.

Repro

1. Configure Synology Chat outgoing webhook to OpenClaw /webhook/synology
2. Send bot command/message in Synology Chat
3. UI shows Processing for a long time (or never clears)
4. OpenClaw may return Missing required fields (token, user_id, text) for JSON/alias payloads

Expected

• OpenClaw should accept real-world Synology payload variants
• Synology UI should not stay stuck at Processing
• Final agent reply should still be delivered via incoming webhook (method=chatbot)

Proposed fix

In extensions/synology-chat/src/webhook-handler.ts:

1. Parse both content types:

   • application/x-www-form-urlencoded
   • application/json

2. Normalize token from multiple locations:

   • body.token
   • query.token
   • headers (e.g. Authorization: Bearer ... / custom token header)

3. Support field aliases:

   • user_id <- user_id | userId | user
   • text <- text | message | content

4. Immediate ACK should be 204 No Content (or empty 200) rather than returning {"text":"Processing..."}.

5. Keep real reply path unchanged: send final output back via incoming webhook (method=chatbot).

Validation criteria

• Synology Chat no longer hangs on Processing
• Final OpenClaw reply still arrives normally in chat

Notes

I locally patched the handler with the above normalization + 204 ACK behavior, and the issue was resolved in my environment.