@.luke - they are similar but distinct. #363256 describes sending special payloads to the configured endpoint notifying of failures
This issue describes supporting webhook events for webhooks as a resource - just like issues/merge-requests/etc. In this model users would need to choose to subscribe to these events, and it would include other things like creation, updates, deletes as well as disabling/enabling them (which are obviously a subclass of updates)
Thank you for clarifying @alexkalderimis! I'll mark them as related.
I've added rate-limited as an event to the description.
Perhaps they should be in the same epic as they're different proposals for similar problems, to keep them together. I'll move #363256 from &6004 into the same epic as this issue &8083. But perhaps they belong somewhere else.
I've added rate-limited as an event to the description.
Although, on second thought rate-limited probably will never make sense unless we punch a hole in the rate limiter for this one type of webhook (which we shouldn't). We rate limit across a whole root namespace now, so all their hooks become rate limited, which would include this webhook! I'll take it out of the description again.
Users are expressing interest in using webhook events to trigger notifications for failures which would go otherwise unnoticed.
Our most recent report from GitLab Premium customer in ZD#331844 would like to use their Teams integration to send notifications when Jenkins jobs fail to start when triggered by GitLab commits submitted in quick succession.
Once we implemented for webhooks, I think this would be possible to extend to integrations, although with extra work. It sounds like an extra filtering ability to select which integration hooks to execute for would be needed.
It probably makes sense to validate that a webhook only subscribes to this one event type and no other (backed up by frontend form logic), to avoid people configuring a webhook to respond to, say, pushes, and webhook failures. Otherwise, I think we'll get into a tangle of not notifying a failure because the hook itself is the failure.
This would also let us screen out this one kind of webhook from triggering webhook failure hooks (avoid loops) at the expense of not being able to be notified of failures of another webhook monitoring hook (which probably conceptually would be an acceptable limitation, double-monitoring gets confusing after a while!).
I think the primary use case for our customers here would be to capture any failed webhooks and be able to redeliver them, such as if their webhook was disabled and many events are backed up until the receiver is fixed/updated.
A webhook is ideal for pushing the data regularly (and reducing traffic), but for managing webhooks, would an API be a better option?
We might also consider the UI options that could be supported if we had such an API.
I think the primary use case for our customers here would be to capture any failed webhooks and be able to redeliver them, such as if their webhook was disabled and many events are backed up until the receiver is fixed/updated.
@g.hickman I agree this would be super useful for people, especially now that GitLab itself can fail hooks it seems like a courtesy to supply this feature. We have #372826 (closed) for this feature.
We might also consider the UI options that could be supported if we had such an API.
I agree a corresponding UI would be helpful too. Seeing a list of just the failures that could be resent would be helpful, and at that point we may as well add the ability to queue their retry.
but for managing webhooks, would an API be a better option?
Perhaps the create, delete, update events in this issue's proposal might not have a use-case.
But the core proposal of sending some kind of push (may as well be via a webhook!) to notify of a webhook failure seems like it has a place. It could then reasonably easily become the basis for another Slack notification event type, but regardless, as a webhook can be left to people to decide how to surface the event in a way where someone can take action.
One of the problems I think we have is that we lack the ability for people to know when a hook fails besides the passive act of browsing the UI. Especially since hooks can fail and then unfail, something might happen without anyone knowing. Because they can now fail on GitLab's side, just being notified of their own webserver errors is no longer enough to be alerted of problems.
I think something like this issue, plus #372826 (closed), could work together quite well. There's also #363256 as a slightly different idea again. There may be other things we could do in this area too that we haven't thought of.