This is related to tracing the consequences of actions, since the updates should only happen once the consequences have completed or an external async effect was called, or a new channel was opened.
If the async effect returned before the pulsemaking was completed, this could be incorporated into the pulse - less pulses seems better, so long as the replay is not affected.
Currently the logs are simply silenced, but the pulses should not be done until the whole tree has quiesced, or some level of activity has passed, like a chain count, exec count - anything.
This is adding non determinism since the timing of the proposer is involved in setting the pulse boundary, but so long as it is within a reasonable range, it is tolerable.
This is related to tracing the consequences of actions, since the updates should only happen once the consequences have completed or an external async effect was called, or a new channel was opened.
If the async effect returned before the pulsemaking was completed, this could be incorporated into the pulse - less pulses seems better, so long as the replay is not affected.
Currently the logs are simply silenced, but the pulses should not be done until the whole tree has quiesced, or some level of activity has passed, like a chain count, exec count - anything.
This is adding non determinism since the timing of the proposer is involved in setting the pulse boundary, but so long as it is within a reasonable range, it is tolerable.