Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(notifications): Don't send failure notifications for cancelled pipelines and stages #663

Merged
merged 6 commits into from
Sep 27, 2019

Conversation

luispollo
Copy link
Contributor

This fixes an issue where Echo would send failure notifications for cancelled stages, and tries to account for a similar scenario with cancelled pipelines where the execution object has two different fields for cancellation status and only one was being checked.

Also added tests to cover some of the basic flows in AbstractEventNotificationAgent, which is where this logic resides.

@luispollo
Copy link
Contributor Author

@emjburns @marchello2000 Please review.

@@ -78,7 +78,13 @@ abstract class AbstractEventNotificationAgent implements EchoEventListener {
return
}

if (config.type == 'pipeline' && event.content.execution?.status == 'CANCELED') {
if (config.type == 'stage' && event.content.canceled == true) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so one repro/failure scenario is, have a "failure" notification on a stage, cancel a pipeline while that stage is running?

I don't understand the second repro case (below)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, i see.... when we cancel the execution, we don't refetch the execution from the db hence canceled = true but status is probably still = running..? but I still don't understand why this doesn't happen always..?

Copy link
Contributor Author

@luispollo luispollo Sep 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that’s what I’m thinking, but I couldn’t quite pin it down, so this was more of a hunch... My guess is that it’s a timing issue/race condition somewhere, but I’m not yet familiar enough with the codebase to find it and after a couple of days I thought this was a reasonable compromise.

I could add some logging around this case, in case it continues to happen...

@luispollo
Copy link
Contributor Author

@emjburns and @marchello2000 Would you please look this over one more time and give it a 👍 if you think it looks good? Thanks!

Copy link
Contributor

@emjburns emjburns left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems reasonable for now!

@luispollo
Copy link
Contributor Author

@gal-yardeni FYI

Copy link
Contributor

@marchello2000 marchello2000 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it looks good to me, would be great to understand what the scenario that gets us into this state but this change will definitely make it better! :)

I will let you rebase and then I can merge it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants