Summary

The @openclaw/nextcloud-talk webhook handler rejects non-message Talk events (file shares, share-link cards, etc.) with HTTP 400 Invalid payload format instead of acknowledging them silently. This pollutes the Nextcloud server log with stack traces every time a user shares a file in a room that has an OpenClaw bot installed, even though the bot was never expected to act on those events.

Environment

• @openclaw/nextcloud-talk: 2026.5.7
• openclaw: 2026.5.7
• Nextcloud: 33.0.2.2
• Nextcloud Talk (spreed): version shipped with NC 33.0.2 (Talk client v23.0.2)
• Node: 24-alpine
• Bot features: webhook, response

Reproduction

1. Install OpenClaw nextcloud-talk channel and register the bot via occ talk:bot:install against an existing room.
2. From the Nextcloud Talk client (iOS/web), share a file into the room (POST /ocs/v2.php/apps/files_sharing/api/v1/shares with shareType=10 / Talk).
3. Nextcloud's spreed app dispatches the webhook to the bot endpoint.
4. The bot responds 400 Bad Request with body {"error":"Invalid payload format"}.
5. Nextcloud logs Bot error occurred, increasing error count with a Guzzle stack trace.

Observed log (Nextcloud side)

"app":"spreed",
"url":"/ocs/v2.php/apps/files_sharing/api/v1/shares",
"message":"Bot error occurred, increasing error count",
"exception":{
  "Exception":"GuzzleHttp\\Exception\\ClientException",
  "Message":"Client error: `POST http://<bot>:8788/nextcloud-talk-webhook` resulted in a `400 Bad Request` response:\n{\"error\":\"Invalid payload format\"}"
}

The same Invalid payload format is also raised on occ talk:bot:setup against a fresh room (likely the setup ping carries a payload shape the handler does not recognize).

Expected behavior

For Talk events the bot is not interested in (or whose schema does not parse), the channel handler should:

• Return HTTP 200 with an empty body (or 204), so Nextcloud does not increment error_count and does not log a stack trace.
• Optionally log at debug level on the bot side that an unknown payload variant was skipped.

The relevant chain is in dist/channel-*.js (WEBHOOK_ERRORS.invalidPayloadFormat) — currently any Zod parse miss returns 400 regardless of whether the event is a chat message the bot is meant to handle.

Impact

• Chat replies still work (error_count is reset on the next successful chat round-trip), but the bot looks unhealthy in occ talk:bot:list output if a burst of file shares lands.
• Nextcloud admin log fills up quickly in active rooms; real bot errors get drowned out.
• If error_count crosses the auto-disable threshold before the next chat message resets it, Talk may move the bot to state=0 and silently stop delivering messages.

Suggested fix

Treat schema mismatch as a non-fatal "not for this bot" condition: when the inbound payload does not match the expected chat-message schema, respond 200 and return early, instead of mapping to invalidPayloadFormat → 400. Keep the 400 path for genuinely malformed JSON / missing signature headers (which are still useful signals).

Happy to send a PR if the maintainers agree on the contract.