tree 8b1d07fad3c3d84dc3e2ada48ac09918f5f4688e
parent 1f3f5208b6e0e253053e32ec09ae22ff21885188
author jmmv <jmmv@google.com> 1550782511 -0800
committer Copybara-Service <copybara-worker@google.com> 1550782603 -0800

Split ActionStatusMessage into separate events.

ActionStatusMessage had a very strange API in the sense that it carried
multiple different statuses but these were not explicitly represented
anywhere: callers had to guess what status was represented by a combination
of the values of the fields in the message.

To fix this, split the status updates into separate events with good names
and types.  This keeps each event restricted to the data it has to carry,
preventing callers from having to guess what is or is not available, and
matches what we do for many of the other action-related events.

Note that it'd be slightly nicer to use an enum of some form so that callers
could be guaranteed to handle all possible status cases... but doing so
results in even more convoluted code because each status needs to carry
different information around.

This change highlights two more deficiencies that I am fixing.  First,
there is no such thing as a "preparing" event separate from an "started"
event so I removed the former representation.  Second, the "messages" in
the status messages were used to update the UI, thus conflating internal
status representations with the specific ways in which they should be
displayed to the users; I just pushed the formatting responsibility to
the UI modules instead.

Necessary cleanup to address https://github.com/bazelbuild/bazel/issues/7345.

RELNOTES: None.
PiperOrigin-RevId: 235051214