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

Handle workunits corresponding to canceled Nodes. #10659

Merged
merged 2 commits into from Aug 23, 2020

Conversation

gshuflin
Copy link
Contributor

@gshuflin gshuflin commented Aug 19, 2020

Problem

cf. #10650 . When a node is canceled by the engine, the engine will remove the future associated with that node without communicating this fact to the workunit store. This means that the store has no idea that a Started but not yet Completed workunit is never going to complete.

Solution

This commit adds a CanceledWorkunitGuard in the with_workunit public interface to workunits. If a workunit completes normally, the last thing it will do is call not_canceled() on the guard, and the guard will do nothing. If the guard is dropped before this happens, though, its Drop implementation will call a cleanup function on the workunit store to remove the workunit from the heavy hitters and display a log message stating that the workunit has been canceled.

@coveralls
Copy link

Coverage Status

Coverage remained the same at 0.0% when pulling cf4989d on gshuflin:workunits-not-completed into de7d5c3 on pantsbuild:master.

@gshuflin gshuflin marked this pull request as ready for review August 20, 2020 01:57
WorkunitState::Completed { .. } => "Completed:",
fn log_workunit_state(&self, canceled: bool) {
let state = match (&self.state, canceled) {
(_, true) => "Canceled:",
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't know this part of the codebase very well. Does it make sense to have WorkunitState::Canceled instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We'll eventually probably want to represent workunit failure as part of the state, but adding that variant to the type now means we have to modify code in the pathway to the streaming workunit handler right now. I think we still need to do a little bit of thinking about how we want to present failed workunits to plugins, and that can come as a follow-up commit to this one.

[ci skip-build-wheels]
[ci skip-build-wheels]
@asherf
Copy link
Member

asherf commented Aug 21, 2020

sgtm

@gshuflin gshuflin merged commit 44422d9 into pantsbuild:master Aug 23, 2020
@gshuflin gshuflin deleted the workunits-not-completed branch August 23, 2020 07:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants