Fix concurrent local activity replay nondeterminism

[paulcacheux]

Problem

When multiple coroutines issue local activities concurrently (e.g. via asyncio.gather), replay can fail with NondeterminismError.

During first execution, local activity resolve_activity jobs arrive in completion order (wall-clock timing). During replay, they arrive in sequence number order. This ordering difference causes coroutines to resume in a different order, assigning different sequence numbers to subsequent commands, which no longer match the recorded markers.

Fix

Sort local activity resolve_activity jobs by sequence number before processing them in _WorkflowInstanceImpl.activate(). This ensures coroutines always resume in scheduling order regardless of execution mode (first-execution vs replay).

The fix is safe for existing workflows:

• Without concurrent local activities: sorting a single item is a no-op.
• With concurrent local activities that replayed correctly (completion order happened to match seq order): the new code produces the same interleaving.
• With concurrent local activities that already failed on replay: they were hitting NondeterminismError anyway.

Test

Added test_workflow_concurrent_local_activity_replay: runs a workflow with two concurrent coroutines each issuing multiple sequential local activities, then replays the recorded history. Without the fix, replay fails with NondeterminismError.

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Sushisource]

Thanks for the contribution!

This is very likely not the right thing to do - resolutions need to come in the same order they were written in, which means whatever order they are in history, not sequence number order.

Additionally, it's the responsibility of Core to do this all properly.

Does the test you've written consistently reproduce an NDE without your fix? If so, something's definitely wrong, but I don't think this is the right solution.

[tconley1428]

Your test reproduced locally for me, but given that the solution is not the one we would want to proceed with, could you open an issue instead, which we can use to track the problem?

[paulcacheux]

Yes I'm going to open an issue with the reproducer (that at least for me is reproducing every time)

[paulcacheux]

here is the issue #1578, thanks for taking a look !