[Feature]: Support incremental composition of parallel operations

オープン
  • 何か問題がありますか？
#614 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@SravyaPeri がすでに取り組んでいます。

2026年8月13日 から。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
静か
技術スタック
java, python
領域
backend-api-design, distributed-systems

調査の方向性

まず packages/aws-durable-execution-sdk-python/src/aws_durable_execution_sdk_python/types.py の現在の Python DurableContext.parallel API から始め、次に Java の ParallelDurableFuture が公開するライフサイクルと比較します。実装前に、登録、完了、リプレイ検証、早期完了のセマンティクスを RFC で明確にします。既存のシーケンスベース API と決定論的なリプレイ契約を維持する、合意済みの加法的な API 設計ができた時点を完了とします。

索引モデルが issue の本文から書いたものです。

説明

enhancement parity

What would you like?

Please add an incremental composition API for Durable Execution parallel
operations.

The current Python API requires the complete sequence of branch functions when
context.parallel(...) is called:

result = context.parallel(
    [run_research, run_analysis],
    name="agent-tasks",
)

This is convenient when every branch is known up front, but it does not let a
workflow create a parallel operation, register and start branches as work is
discovered, and then explicitly seal and await the operation.

Incremental composition is especially useful for agentic AI workloads. An
agent may checkpoint a generated plan, discover tool calls or specialist tasks
from that plan, and add branches as those tasks become known. Ready work could
start immediately, subject to max_concurrency, while later branches are
still being assembled.

The Java Durable Execution SDK already exposes this lifecycle:

ParallelDurableFuture parallel = context.parallel("agent-tasks");
try (parallel) {
    DurableFuture<ResearchResult> research =
        parallel.branch("research", ResearchResult.class, branch -> runResearch(branch));

    if (plan.requiresReview()) {
        DurableFuture<ReviewResult> review =
            parallel.branch("review", ReviewResult.class, branch -> runReview(branch));
    }
}

parallel.branch(...) registers and starts each branch, and closing/getting the
parent seals registration and waits for completion.

Benefits include:

  1. Branches can be registered and started as a workflow plan is constructed.
  2. Ready work need not wait for the entire branch sequence to be materialized.
  3. Conditional and dynamic fan-out can use normal control flow without first
    building an intermediate list.
  4. Individual branch handles can compose naturally with later workflow logic.
  5. The programming model supports agentic orchestration and other workloads
    where the amount of work emerges incrementally.
  6. It improves cross-SDK parity with Java.

The existing sequence-based context.parallel(...) API should remain available
for the common case where all branches are predefined.

Possible Implementation

An additive builder/handle API could provide a registration phase followed by
an explicit completion phase. The exact naming is open for discussion; this is
only an illustrative Python shape:

parallel = context.create_parallel(
    name="agent-tasks",
    config=ParallelConfig(max_concurrency=4),
)

research = parallel.branch("research", run_research)

if plan.requires_review:
    review = parallel.branch("review", run_review)

summary = parallel.complete()
research_result = research.get()

A context-manager variant could also make the completion boundary explicit:

with context.parallel_builder("agent-tasks") as parallel:
    research = parallel.branch("research", run_research)
    if plan.requires_review:
        review = parallel.branch("review", run_review)

research_result = research.get()

The API should ideally:

  • allow branches to be registered until complete() or context-manager exit
    seals the operation
  • allow registered branches to start immediately, respecting
    max_concurrency
  • preserve branch names and registration order for deterministic replay
  • retain existing completion strategies, serialization, summary generation,
    and per-branch error behavior
  • reject branch registration after completion has begun
  • preserve the existing sequence-based API as a convenience wrapper

Incremental registration must not weaken Durable Execution's deterministic
replay contract. For agentic workloads, model-generated plans or tool-call
sets should first be produced in a checkpointed step. Replay should then
register the same branches in the same order, with the SDK detecting
inconsistent registration.

Is this a breaking change?

No. This can be introduced as an additive API.

Does this require an RFC?

Yes. The registration lifecycle, completion semantics, replay validation, and
interaction with early completion strategies should be specified.

Additional Context

References:

主要言語
Python
スター
58
フォーク
32
平均マージ
1日 6時間
マージ済み PR（30日）
80

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

aws/aws-durable-execution-sdk-python のほかの issue

aws/aws-durable-execution-sdk-python の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。