The webhook system has a bit of a catch-22 problem.
Imagine there’s a team that is using GitLab and also some kind of 3rd party integration that uses token of the person who set up integration.
That integration might add some webhooks to a project using that token (or a user might add them manually) and then interact with the API when a webhook is received, a fairly common pattern.
The catch-22 happens when that user loses access to the GitLab project for some reason (perhaps they left the team, very common unfortunately). The integration sees that the token no longer gives access to do the job, so it might want to remove the webhook. But the catch is that without that access it cannot remove the webhook either!
So all too common is that:
- a person sets up some sort of integration that includes webhooks
- that person leaves company and loses access to the gitlab groups/projects
- the integration starts failing, because it has no access
- the integration is unable to remove webhooks so this repeats until someone at that company notices that webhook, which sometimes takes years and does something about it
It would be to mutual advantage of gitlab and integration authors that integrations are able to reject any further calls from a particular webhook without having project access, because why waste resources calling something it doesn’t want to be called? Currently the response status code / body for webhooks is being ignored, so perhaps there could be an http status code or special response body that tells gitlab to remove this webhook?