The plugin currently offers a "debouncing" function which helps with triggering a lot of API webhooks. We use this, combined with running the queue only once every 5 minutes via crontab, to ensure our static generation command in our CI/CD system is triggered no more than once every five minutes.
However, if the queue/run command is running, and you start editing entries, we've noticed a lot of webhooks being called only a few seconds apart. This makes sense because the webhooks job quickly disappears from the queue, but Craft may also be doing stuff like rebuilding search indexes, and it will spawn new webhook jobs because the last one disappeared already but the queue/run command is still running.
Additionally, this doesn't work if you don't use crontab / cli commands for running your queue, and you have to limit the entire queue run frequency to how often you want to call the webhook.
As such I'd like to request for a more robust debounce functionality, for example a setting to only run a specific webhook once every x minutes, and using the database instead of the queue itself for debouncing?
Description
The plugin currently offers a "debouncing" function which helps with triggering a lot of API webhooks. We use this, combined with running the queue only once every 5 minutes via crontab, to ensure our static generation command in our CI/CD system is triggered no more than once every five minutes.
However, if the queue/run command is running, and you start editing entries, we've noticed a lot of webhooks being called only a few seconds apart. This makes sense because the webhooks job quickly disappears from the queue, but Craft may also be doing stuff like rebuilding search indexes, and it will spawn new webhook jobs because the last one disappeared already but the queue/run command is still running.
Additionally, this doesn't work if you don't use crontab / cli commands for running your queue, and you have to limit the entire queue run frequency to how often you want to call the webhook.
As such I'd like to request for a more robust debounce functionality, for example a setting to only run a specific webhook once every x minutes, and using the database instead of the queue itself for debouncing?