Closed Webhook Recursion Loop: API updates trigger infinite events

LeoTR

LeoTR

Active member
Licensed customer
Affected version
2.3.7.
I'm reporting a critical architectural gap in the Webhook system (specifically post.update / thread.update). The current implementation lacks "origin-awareness," meaning it treats API-based updates exactly the same as human interactions.

This creates a dangerous "infinite recursion loop" for anyone using two-way automation.

The Loop Scenario (How it happens):

  1. A user posts a thread -> Webhook fires.
  2. An external automation tool (middleware) receives the data, processes it (e.g., via OpenAI/LLM), and writes back to the thread using the XenForo API.
  3. The Failure: XenForo detects this API update and fires the webhook again.
  4. Result: The automation runs again on its own output. This repeats indefinitely (thousands of times) until the server crashes or limits are hit.
Why This is Dangerous (Financial & Infrastructure Risk):This isn't just a server load issue; it’s a financial liability.

  • The "Bankruptcy" Risk: If the workflow triggers a paid service like OpenAI (GPT-4) or uses a metered automation platform (Zapier/Make), this loop can drain a credit card or monthly quota in minutes. A single thread update can unintentionally trigger 1,000+ billable executions.
  • Operational Denial: It effectively DDoSes the external service and the XenForo job queue.
The Root Cause (Missing Filters):As seen in the Webhook configuration, we can filter by "Forum" or "Event Type," but we cannot filter by User Group.Since API actions usually run under a specific "Bot" or "Admin" user, the inability to exclude specific User Groups from triggering webhooks is the primary cause of this loop.

Proposed Solutions:

1. The Primary Fix (Admin Panel):Please add a "User Criteria" or "Exclude User Groups" tab to the Webhook definition page.

  • Logic: "If the action is performed by [Bot User Group], DO NOT fire the webhook."
  • This is the standard way to prevent recursion in most other platforms.
2. The Alternative Fix (API Side):If UI changes are too complex for now, please allow a parameter in the REST API endpoints (e.g., XF-Skip-Webhook: true header or silent=1 in body) to strictly bypass webhook triggers for that specific request.

This is a necessary safeguard for any modern event-driven integration. Thanks for looking into this.
 
Automated triage: As designed

Thank you for reporting this issue. Webhooks are sent once each time subscribed content is saved, whoever made the change. They can currently be filtered by event and content criteria such as forum, but not by user or user group. Avoiding a feedback loop needs to be handled in the receiving integration, and options to filter by user or skip webhooks for API requests would be a new feature, best raised as a suggestion.

This is an automated assessment. A member of staff may review and update it.
 
Back
Top Bottom