Patch #44465
openRun webhook deliveries on a dedicated queue
Description
WebhookJob runs on the default queue, like every other Redmine async job (except mails).
The issue : a single unreachable endpoint could quickly saturate this queue: each delivery waits for the 60second timeout before failing, so a worker with 3 threads processes at most 3 deliveries per minute. Meanwhile every issue update enqueues new ones, the queue grows faster than it drains, and all other jobs on the default queue wait behind them.
Email notifications would be spared only because the mailers queue has its own worker.
I propose to move webhook deliveries to their own queue, so that administrators can give them a dedicated worker and a failing endpoint cannot hold up the rest of the application:
--- a/app/jobs/webhook_job.rb
+++ b/app/jobs/webhook_job.rb
@@ -18,6 +18,8 @@
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
class WebhookJob < ApplicationJob
+ queue_as :webhooks
+
def perform(hook_id, payload_json)
if hook = Webhook.find_by_id(hook_id)
if hook.user&.active?
Administrators who list their queues explicitly already include the mailers queue (Action Mailer's default) ; they would also have to list the "webhooks" queue.
Related issues
Updated by Vincent Robert about 1 month ago
- Related to Feature #29664: Webhook triggers in Redmine added
Updated by Marius BĂLTEANU about 1 month ago
- Assignee set to Marius BĂLTEANU
- Target version set to 7.1.0
Updated by Marius BĂLTEANU 1 day ago
Holger Just, Jens Krämer, do you see any issue if we move webhooks to their own queue as Vincent Robert propose?
Updated by Holger Just about 8 hours ago
That should be fine. By default, the default worker handles all jobs if I'm not mistaken. Thus, the default config should probably work unchanged.
We should definitely mention this change in the release post though so that admins who use custom queue workers become aware of the need to check their configuration.