wallyworld, right, so, the operation executor should I think only be writing state changes in response to actual operations being prepared/executed/committed
 wallyworld, adding new out-of-band ways to set state at arbitrary times feels pretty terrifying
 wallyworld, especially since all the ops accept a state and return a new state based on that one
 wallyworld, and we'll need extra fancy fiddliness to reconcile how that state *might* have changed in the process of running it
 wallyworld, also somewhat surprised that we seems to be ignoring errors in status-settings
 wallyworld, shouldn't that be enough to straight-up fail the hook? just the same as failing to (say) write a cached relation setting?
 wallyworld, (sorry, I mean in the automated status-setting)
 wallyworld, I think it's the same as (almost) any other error: something went wrong, we no longer know what remote state is with any degree of certainty, fail out right now and don't make things any worse by proceeding based on flawed assumptions
 wallyworld, wait a mo
 wallyworld, the only step that *can* do that is Execute, right?
 wallyworld, and execute always has access to a runner/context, so it can literally just ask
 wallyworld, commit only happens either after a fully-completed execute step, *or* when skipping past a failed hook, in which case I don't think we care what the failed hook may or may not have tried to do
 wallyworld, the user's explicitly acknowledged it's so broken that they'd rather just pretend nothing happened at all
 wallyworld, but either way commit shouldn't need to look at the ocntext anyway
 wallyworld, am I making sense?
* fwereade is probably not making sense...
<fwereade> wallyworld, also
 wallyworld, the state change needs to be decided at the operation level because many different ops use runners