Differential D21423

Give Futures clearer start/end and exception semantics
ClosedPublic
Actions

Authored by epriestley on Jul 23 2020, 5:07 PM.

Details

Reviewers: None
Maniphest Tasks: T13555: In "ExecFuture", "proc_get_status()" may be passed NULL, possibly leading to a daemon stall
Commits: rARCccd39feb6d3b: (stable) Promote 2020 Week 29
rARCceb082ef6b29: Give Futures clearer start/end and exception semantics

Summary

Ref T13555. Currently:

If an exception is raised in "start()", the exception state is not set on the future.
Futures do not always call "startFuture()" before starting, and do not always call "endFuture()" once they become resolvable.
If you start an ExecFuture which immediately fails and then call "getPID()" on it, you get an unclear exception.

Simplify these behaviors:

In FutureIterator, only start futures which have not already started.
When starting a future on any pathway, run start code.
When a future becomes resolvable on any pathway, run end code.
Raise a more clear exception when calling "getPID()" on a future with no subprocess.

Test Plan

Faked a failing subprocess with "$proc = null", ran "bin/phd debug taskmaster" etc. Got clearer errors and more consistent future lifecycle workflows.