Send notifications when generic/unhandled failures #3864
Conversation
|
@agjohnson can you take a look at this PR?
|
|
Hrm, yeah I'm not sure of the best pattern to use here. Moving all this logic into context managers was the original fix to centralize steps like build reporting. It seems we're just leaking more and more state out of the context managers. |
|
I think if we want to accept the duplication of this logic for now, we should continue to test this and merge it. We can come back and cleanup and implement #3984 to reduce all of this duplication. |
|
Regarding testing, is it possible to throw and exception as a mock side effect on one of the calls that would normally trigger this bug? |
humitos
force-pushed
the
humitos/notifications/generic-failures
branch
from
3472fc3
to
f852fb9
Compare
|
@humitos what is the state of this? Can it be closed, since it was just a test? |
|
@ericholscher this isn't just a test. In fact, this solves a problem reported in the corporate site: when a generic exception happens an email is not sent to the user. This PR makes that email/notification to go out properly. The problem on this PR is that I didn't find a way to write an accurate test because our update task flow exception handling depends on |
humitos
force-pushed
the
humitos/notifications/generic-failures
branch
2 times, most recently
from
9905696
to
2fec3a6
Compare
humitos
removed
the
PR: work in progress
|
Needs conflicts resolved. |
humitos
force-pushed
the
humitos/notifications/generic-failures
branch
from
2fec3a6
to
41a05f7
Compare
|
Conflicts solved and this should be ready to merge after tests pass. |
This PR used to have a test case but it wasn't accurate. I decided to remove it and leave this small piece of code untested (send an email on unhandled failures). It shouldn't be terrible and it does fix an issue that our customer are having at the moment.
We can improve this later when a re-work is done around the
UpdateDocsTaskand how all the steps of this task are managed.