Note: the assumption here is that we'll always run through all the phases in their defined order once, before we run other phases. E.g. we can't have two read calls in a row before first hitting an earlyRead for a setup like afterRender({read: fn, earlyRead: fn}). I think that's true based on the code that executes them, but it's worth calling out.

Somewhat of a tangent: one thing we discussed just now is how this behaves w.r.t. an exception in one of the phases. Currently I believe this would continue to run the subsequent phases, passing the resulting state of the phase that ran prior to the one that threw an exception (based on how pipelinedArgs is updated after the callback has executed).

I wonder if we should cancel all subsequent callbacks in case of an exception, effectively dropping callbacksLeftToRun to 0 to let it clean up. It probably makes sense for afterRender to have similar behavior so that would need some sort of a different approach.

The above is kind of out of scope because this PR makes things clearly more correct than what we have today, but it would be beneficial to have tests for the behavior in the presence of exceptions.

Yeah agreed that it would make more sense that the chain gets interrupted if one of the callbacks throws, although the current behavior seems quite deliberate to me (reading the code). Maybe @devknoll has context on it?