Concurrent external events, timers, and workflow execution in Durable Workflow V2

[bendbot]

Hi, I’m evaluating Durable Workflow V2 for a long-running trading bot and I’m trying to understand whether it supports one particular execution model.

I have a long-running Strategy Workflow representing the lifecycle of a market.

During its execution, there are several independent external processes/events:

1. An RTDS resolver may produce a pre-resolution result.
2. A WebSocket resolver may produce a pre-resolution result.
3. A client-based resolver becomes available after a fixed delay (e.g. 180 seconds) and may then take an arbitrary amount of time to resolve the market.

The important part is that these processes are independent.

For example:

T+0
Market ends.

T+0
RTDS, WebSocket and the delayed Client resolution process are started.

T+20
An external HTTP webhook receives an RTDS result.

The RTDS result must immediately trigger an Activity and, once that Activity completes, the Strategy Workflow must continue:

RTDS pre-resolution
↓
pattern detection
↓
additional analysis
↓
trading decision
↓
trade execution

At the same time:

• WebSocket processing may still be waiting for an external event.
• Client resolution must continue independently.
• At T+180, Client resolution must start regardless of the state of RTDS or WebSocket.
• Client resolution may take much longer than the RTDS/WebSocket processing.
• The Strategy must not wait for all resolution sources before continuing.

There may also be multiple external events/signals during the lifetime of the workflow.

For example:

• RTDS event can arrive.
• Another RTDS event can arrive later.
• WebSocket event can arrive independently.
• Client resolution can complete independently.

The workflow therefore needs to support something conceptually like:

external event A
    ↓
process A
    ↓
continue main workflow

while at the same time:

external event B
    ↓
process B

and:

timer
    ↓
process C

The critical requirements are:

• Multiple independent activities/processes must be able to wait for external events concurrently.
• External events must be able to carry arbitrary payloads.
• An external event must be routed to the appropriate waiting process/handler.
• Processing one event must not block unrelated timers or event handlers.
• The main workflow must be able to continue as soon as the required event/result is available, without waiting for unrelated processes.
• Some processes may continue running after the main workflow has moved to the next stage.
• Everything must remain durable and deterministic across worker restart and replay.
• Duplicate events and events arriving while another Activity is executing need well-defined behavior.

I initially tried to model this using Signals, timers and concurrency primitives, but I’m not sure whether V2's execution model supports this combination directly.

My main question is:

What is the recommended Durable Workflow V2 pattern for this kind of problem?

More specifically, does V2 provide a native way to have multiple concurrent long-lived event consumers/processes, each receiving external signals with payloads, while allowing the main workflow to react to one result without waiting for all other consumers?

I’m not necessarily looking for a specific implementation. I’d like to understand what execution model V2 is designed to use for this scenario, and whether there are any fundamental limitations I should be aware of before building the system around it.

[rmcdaniel]

Thanks for laying out the timing and failure requirements this clearly. They expose an important boundary in the current v2 prerelease.

The short answer is: not as one native workflow construct today.

V2 has the underlying pieces: durable external signals, payload-bearing messages, timers, activities, child workflows, and deterministic parallel groups. The current parallel primitive is an all-members join barrier. It does not start several durable branches, return when the first selected branch resolves, and leave the remaining branches under explicit lifecycle control.

Workflow code is also logically single-threaded and replayed in a deterministic order. Activities may execute concurrently on workers, and an external event that arrives while an activity is running is durably recorded rather than lost, but a sequential workflow does not run a second mutable event handler in parallel with the unresolved activity.

Recommended model with the current prerelease

I would use a coordinator plus independently durable resolver workflows:

1. The Strategy workflow owns market state and trading decisions.
2. RTDS and WebSocket ingress adapters send results with stable source event IDs. They should not hold activities open while waiting for callbacks.
3. The client resolver is an independent workflow that owns the T+180 durable timer and then performs its resolution work.
4. Each resolver sends its result back to the Strategy workflow.
5. The Strategy consumes those results, runs bounded analysis activities, and advances when the result it needs is available.

If resolver work must continue after the Strategy has advanced or completed, use independently started top-level workflows rather than relying on a detached-child behavior. Start the Strategy and resolver workflows together from the client or control process. That keeps the T+180 deadline independent of whatever the Strategy is currently waiting on.

External payloads should use the portable payload value set, or an external payload reference for large/application-owned data. Give each inbound event a stable idempotency key so repeated delivery can be deduplicated by source identity. Activities remain at-least-once work, so trade execution also needs a business or activity-execution idempotency key at the exchange boundary.

This topology is durable across worker replacement and replay, but it is more manual than the single-workflow model in the question.

Should the native model grow?

Yes, I think the missing abstraction is worth adding. It should be structured durable concurrency, not arbitrary background threads:

• durable handles for independently started activities, child workflows, timers, and external-event waits;
• a deterministic select/first-completion operation whose winner is recorded and stays the same on replay;
• explicit handling for non-winning operations, so the workflow can continue them, await them later, or cancel them.

That is a protocol and replay feature across the runtime and SDKs, not merely a convenience helper. I would not suggest provisional syntax until those lifecycle and replay semantics are defined. For the current prerelease, the coordinator plus independent resolver-workflow topology above is the safe design boundary.

[bendbot]

Thanks, this clarifies the boundary.

Based on your recommendation, I think I’ll use the coordinator + independently started top-level resolver workflows for the current v2 prerelease.

The topology I’m planning is:

StrategyWorkflow
├── starts RtdsResolveWorkflow
├── starts WebSocketResolveWorkflow
└── starts ClientResolveWorkflow
        │
        └── T+180 durable timer → client resolution

RTDS/WebSocket workflows receive their external result via signals, execute the corresponding resolution activity, and then signal the StrategyWorkflow with the result.

The StrategyWorkflow does not wait for all resolvers. It continues as soon as the required pre-resolution result is received, while the ClientResolveWorkflow remains independent and can continue until the final resolution is available.

This also means that the resolver workflows have their own deterministic IDs per market and can continue independently if the StrategyWorkflow has already advanced.

For the current v2 prerelease, this seems like the cleanest fit for my use case.