-
Couldn't load subscription status.
- Fork 1.4k
Description
If a build is canceled and a task is ICancelableTask then MSBuild calls Cancel() on it
| private void Cancel() |
The idea is that the task can finish more quickly, perhaps cleaning up intermediate files.
However there are several possibilities
- task does not implement ICanceleableTask -- correct
- task finishes early without completing its work, does any cleanup and returns false. -- correct and ideal
- task ignores cancelation and returns normally -- possibly unnecessarily slow
- task ignores cancelation because the expensive work was already completed and it's just finishing up (eg its setting its output parameters or logging something) and returns success -- harmless
- task finishes without completing its work, possibly does not clean up, and returns true -- clearly a bug
Ideally we would know if a task wasn't handling cancelation optimally. To do this we might consider changing to treating every canceled task as a failure.
This would mean the last 3 cases would all begin to fail. That should not be a breaking change, because the build is guaranteed to be failing now as it began cancelation by definition. However it will cause the task to show as a failure in the console and the log. And if we see the task didn't clean up, we know for sure that it has a bug, as we know that it received the cancelation signal before it returned.
Edit: conversely this would mean tasks need not return any particular code in the cancellation case. Hmm, I have mixed feelings whether this change would give much benefit.
The change would be here, something like changing to taskReturnValue == TaskInstanceExecute() && !_cancelled;
| taskReturnValue = TaskInstance.Execute(); |
Aside -- if we could go back in time, we would certainly have made ITask.Execute() void returning, and consider the task a success iff no errors were logged and no attempt was made to cancel it.