This model is a bit more intuitive and also fits in with what I have come to realize is really the most appropriate model for Core based languages, where everything that happens in a workflow task is "applied to state" synchronously, and then the way routines proceed to run is largely up to the language runtime (or our deterministic version thereof). Ideally, all Core langs (really, all of them, but we won't go back to change that) follow that model - state is updated synchronously, then stuff runs until we're blocked.
There is a really nice test here @mjameswh added that I think all async languages should have some form of that helps us understand exactly how routines will proceed.
I'm not sure if making this change will actually have consequences to the realized python behavior. In any case it should probably be protected with a flag if we make it.
Python currently applies jobs in a few different batches: https://github.com/temporalio/sdk-python/blob/main/temporalio/worker/_workflow_instance.py#L325
In TS, we changed this to only do one batch, and then run the event loop: https://github.com/temporalio/sdk-typescript/pull/1488
This model is a bit more intuitive and also fits in with what I have come to realize is really the most appropriate model for Core based languages, where everything that happens in a workflow task is "applied to state" synchronously, and then the way routines proceed to run is largely up to the language runtime (or our deterministic version thereof). Ideally, all Core langs (really, all of them, but we won't go back to change that) follow that model - state is updated synchronously, then stuff runs until we're blocked.
There is a really nice test here @mjameswh added that I think all async languages should have some form of that helps us understand exactly how routines will proceed.
I'm not sure if making this change will actually have consequences to the realized python behavior. In any case it should probably be protected with a flag if we make it.