Improve web-hook failure state cache
What does this MR do and why?
This makes the following changes:
- uses the Redis shared state rather than the rails cache, to allow touching the cache from more places safely
- intelligently sets the cached value of any-hook-failed when a hook succeeds or fails. If it succeeds, then if the state was previously failing, we query sibling hooks to possibly clear it. If it is now failing, we don't have to do that query, and can safely mark it as failed.
Why do we do this?
- These changes ensure that if a hook fails, the cache is invalidated immediately, and if a hook succeeds, the staet is is cleared so that users do not see irrelevant notifications
- Additionally, this reduces the time between a hook failing and any notiication being shown to users.
How to set up and validate locally
- Set a project web-hook, ideally with a failing response
- Visit any project page (issues, overview) - see that there is no banner
- Cause 4 failures
- Visit any project page (issues, overview) - see that there is a banner immediately visible
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 Bojan Marjanovic