Update GroupHook.select_active to include non-executable hooks
What does this MR do and why?
We updated Group Hooks to not be disabled when they receive failing responses. We also need to update the hook selection mechanism.
See: #387938 (closed)
How did this get fixed?
Rather than having auto-disable functionality in the super-class (WebHook
) that is then selectively
disabled, the behavior is moved to two concerns that are included selectively in hook classes.
Currently only project hooks are auto-disabling.
This also involved moving the test code out the super-class.
Database
Two queries changed:
Executable webhooks:
Disabled webhooks:
Screenshots or screen recordings
How to set up and validate locally
Steps to reproduce
- Setup a group webhook pointing to: https://httpstat.us/500 for comment events
- Make 5 comments
- Check the hook details
- You'll see 5 recent events with 500 responses and no indication that anything is wrong (e.g. no indicator that the hook is disabled temporarily or permanently)
- Wait a while
- Make another comment
- Check the hook details
- You see a new event :)
whereas, for project hooks you should see:
- Setup a project webhook pointing to: https://httpstat.us/500 for comment events
- Make 5 comments
- Check the hook details
- You'll see 3 recent events with 500 responses and an indication that something is wrong (specifically an indicator that the hook is disabled temporarily)
- Make another comment
- Check the hook details, see that there is no new event
- Wait one minute
- Make another comment
- Check the hook details
- You see a new failed event, and the back-off time will have doubled
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Alex Kalderimis