[Feature]: Support incremental composition of parallel operations

Aberta
  • Algo errado?
#614 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@SravyaPeri já está trabalhando nisso.

Desde 13/8/2026.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Pouca atividade
Stack de tecnologia
java, python
Domínio
backend-api-design, distributed-systems

Direção de pesquisa

Comece com a API atual Python DurableContext.parallel em packages/aws-durable-execution-sdk-python/src/aws_durable_execution_sdk_python/types.py e, em seguida, compare o ciclo de vida exposto por ParallelDurableFuture do Java. Especifique em um RFC a semântica de registro, conclusão, validação de replay e conclusão antecipada antes da implementação. Considera-se concluído quando houver um design de API aditivo acordado que preserve a API existente baseada em sequência e o contrato de replay determinístico.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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:

Linguagem predominante
Python
Estrelas
58
Forks
32
Merge médio
1d 6h
PRs com merge (30d)
80

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de aws/aws-durable-execution-sdk-python

Todas as issues de aws/aws-durable-execution-sdk-python

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.