How are incoming webhooks processed? about webhook HOT 6 CLOSED

@jzimmek,
Out of curiousity, how would you propose webhook to handle this? Do you mean for webhook to hold HTTP requests open/idle until your blocking script finishes? Or are you expecting webhook to queue the hook request (internally) and immediately respond to the request with a HTTP 200 success code?

I would suggest writing a simple shell command to add requests/jobs to Redis (persistent storage), and then have an app that empties the redis queue one job at a time.

from webhook.

As a late note to this ticket, maybe it can be helpful to some:

I used task spooler to queue tasks triggered by webhook calls, which worked nicely.
In my use case I did not want additional tasks to be queued if there is already one queued (as all tasks perform the same action). This was also easily possible using task spooler by checking the status of the last task that has been added.

from webhook.

It does so in parallel, launching shell command for every successful trigger. It is intended to act as a bridge between HTTP and shell. Following the unix philosophy, the queuing and locking system should be done as a separate tool that does just that thing and does well. :-)

from webhook.

If you happen to develop such tool I would gladly link to it in the webhook README page :-)

from webhook.

I would propose to support at least some control over how concurrency in webhook is handled. Without knowing about the inner details of webhook I would add

1. Add new webhook parameter "concurrency_strategy", which defines the global (default) behavior for all hooks
2. Add new property "concurrency_strategy" in the hook definition, which allows to define the behavior per hook

The following concurrency strategies come to mind:

1. "parallel", the default, which behaves as is now

2. "skip", does not execute command if an existing hook command (same hook id) is already running. but respond with http 200

3. "fail", does not execute command if an existing hook command (same hook id) is already running. but respond with http 500

4. and 3) will already solve a lot of use cases and should be fairly easy to implement.

The idea of having some queueing system sounds somehow nice, but I see your point that this might be a better fit for a different tool and not be part of webhook itself.

Nevertheless, having a "concurrency_strategy" flag in place, I would think about an additional option:

4. "custom", this strategy will communicate with some external script/command. Not sure how this should behave in detail or if it is really necessary, but it would at least fit into this "concurrency_strategy" thing.

from webhook.

At the moment I do not have much time available on my hands, so I won't be implementing this, at least not anytime soon :-(

If you would like to contribute and implement the proposed solution, I would be more than glad to review your code and merge it.

Cheers! 👍

from webhook.