Await Unit Sequences ​
These diagrams show how the await unit model parks and resumes QUEUE_ASYNC executions.
Unary Await ​
Suspension is normal control flow. It should not be logged as a failed step or routed through recovery as an exception.
One-To-One Over Stream ​
ONE_TO_ONE over a Multi is a stream of unary awaits inside one owning unit. This is the model used by csv-payments: each PaymentRecord is one input unit and each provider completion is one output unit.
For brokered await transports, the preferred queue-async path is live. AwaitStepSupport opens a live await session for the unit, source dispatch is bounded by the configured in-flight window, and each completion is recorded before it is emitted to the resumed suffix. If that live session is unavailable, the coordinator falls back to durable item continuations.
Completion may arrive out of order. The live path can process accepted completions as they arrive; durable replay and aggregate release preserve item identity by reading completed item interactions by itemIndex.
Await Unit Gatekeeper ​
The await unit is the durable shape for the boundary. In the live path, it is the identity, ordering, and dedupe anchor for item interactions. In the fallback path, it also gates release so completions cannot race ahead of durable parent suspension. For aggregate cardinalities, it defines what must be replayed together.
For ONE_TO_ONE over a stream, the unit groups item interactions for ordering, dedupe, live-session identity, and fallback release. It is not provider-side batching. For aggregate cardinalities, the unit is the batch because the runtime materializes the relevant side of the boundary.
CSV Payments Itemized Await ​
This is the concrete connector-first csv-payments shape. Await Payment Provider owns the Kafka boundary, the approved and unapproved status branches can run per completed item through the live await session, Finalize Payment Output performs the mandatory terminal merge, and Object Publish writes output chunks before success is committed.
The model is itemized until the next aggregate or terminal boundary. If an authored downstream step is MANY_TO_ONE or MANY_TO_MANY, durable fallback resumes the parent execution there with the collected ordered item outputs. If the suffix remains itemized through the terminal output, Object Publish owns final grouping and object writes.
Durable Item Continuation Recovery ​
The durable fallback has two separate progress boundaries for every item: provider completion and child continuation completion. A provider response is not aggregate progress by itself. TPF first persists the admitted response, then records the child continuation result, then records the idempotent continuation-completion fact for that item. The parent is eligible for release only when every required continuation fact and every required child execution are durably successful.
Concurrent Child Mutation ​
An item child is a durable materialization record. A queue worker can claim it between creation and the continuation flow's first compare-and-swap write. That changes the child version but does not mean the item failed. The continuation flow reloads the child from durable state and retries the success write using the refreshed version when the child is still QUEUED or RUNNING.
The retry is deliberately limited to pending child materialization. A child that is already SUCCEEDED is idempotent. A failed, cancelled, or otherwise terminal child is not overwritten; the continuation remains a real failure. This keeps a version race from becoming a parent-fatal error without allowing a stale worker to rewrite a semantic terminal outcome.
Restart And Reassignment ​
No worker-local claim or completion observation proves aggregate readiness. A fresh runtime uses the await unit and durable child executions to reconstruct progress. If a prior process made a child successful but stopped before writing its continuation fact, the next completion reconciles that missing fact from the child record. The reconciliation claim merely coalesces duplicate scans; it is never correctness state.
Edge-Case Rules ​
| Situation | Durable rule | Result |
|---|---|---|
| duplicate provider completion | interaction completion is idempotent | no additional semantic continuation progress |
| conflicting completion | the admitted interaction contract remains authoritative | reject the conflicting completion |
| provider completion before parent suspension | completion persists, but dispatch waits for dispatchComplete and parent WAITING_EXTERNAL | no premature continuation |
| final provider completion with a missing child fact | read ordered durable children and repair only facts backed by SUCCEEDED children | parent remains held until every required child is successful |
| concurrent child version mutation | reload durable child and retry only QUEUED or RUNNING materialization | recoverable CAS race does not fail the parent |
| duplicate parent release | parent compare-and-swap is the semantic admission point | one accepted parent advance; duplicate physical attempts are harmless |
| restart after child completion or parent release | reconstruct from the await unit, interactions, child executions, and parent record | no worker-local state is needed |
| terminal parent path | release capacity, claims, interactions, continuation facts, and child work | no orphaned pending state |
Terminal Materialization Boundary ​
An itemized suffix can leave the final business step with a materialized terminal value. Queue async represents the required terminal commit as a synthetic cursor whose currentStepIndex equals the generated pipeline step count. That cursor is a coordinator boundary, not another business step: it must publish and commit the already materialized canonical value without encoding it for a remote transition-worker invocation.
This distinction matters under burst load. Sending a 1,000-item terminal result through a no-op worker call adds a large, competing transport operation after all business work is done. It can delay publication even though the durable execution is otherwise ready to finish. The coordinator instead retains the materialized value, performs the normal terminal publication, and commits success.
The ordinary worker path still applies while currentStepIndex names a generated business step. Only a non-await MATERIALIZED_MULTI terminal cursor is coordinator-owned; it is not a shortcut around business execution, await admission, persistence, or terminal publication. A terminal cursor that resumes from an await still loads the canonical completion payload and enters the normal worker path before publication.
Aggregate Unit ​
ONE_TO_MANY, MANY_TO_ONE, and MANY_TO_MANY are aggregate interaction units. The runtime materializes the relevant side of the boundary so replay has one stable unit to restart.
This deliberately avoids partial-output checkpointing inside the interaction unit. TPF owns retry/replay of the unit as a whole.
Timeout And Resume ​
Completion admission follows the opposite path: complete the interaction, update the unit, and resume the execution only when the unit is complete.