-
Couldn't load subscription status.
- Fork 46
Description
Description
Completing an add-on review consists of several steps, like submitting the review by the reviewer using the form, changing version or add-on status, signing a file, recording the activity internally, talking to cinder, using socketlabs to send the email etc.
Internal failures are usually caught by, for instance by failing form validation or raising another error somehow to notify the user (reviewer) that something went wrong.
Failures in dependencies, e.g. not being able to get the necessary information from cinder to build an appeal link (which is needed to send the email), or the email itself failing to be sent out, are currently often transparent and not visible to stakeholders. From a reviewer's point of view, it looks like as the review completed successfully.
When such a failure happens, add-ons operations should be notified in slack (channel tbd) so that they can pause review temporarily until the issue is resolved.
Do we also want to sent recovery notices? Is that something we are planning to do for alerts going to Engineering?
Acceptance Criteria
### Milestones/checkpoints
- [ ] Failure in the automated process of completely executing an add-on review should send out a slack alert to inform reviewers and ask them to pause reviewing temporarily.
Checks
- If I have identified that the work is specific to a repository, I have removed "repository:addons-server" or "repository:addons-frontend"
┆Issue is synchronized with this Jira Task