[Feature]: Support incremental composition of parallel operations

Abierto
  • ¿Algo no está bien?
#614 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@SravyaPeri ya está trabajando en esto.

Desde el 13/8/2026.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
java, python
Área
backend-api-design, distributed-systems

Línea de trabajo

Comienza con la API actual de Python DurableContext.parallel en packages/aws-durable-execution-sdk-python/src/aws_durable_execution_sdk_python/types.py y compara después el ciclo de vida expuesto por ParallelDurableFuture de Java. Especifica la semántica del registro, la finalización, la validación del replay y la finalización temprana en un RFC antes de la implementación. Se considera terminado cuando exista un diseño de API aditivo acordado que preserve la API existente basada en secuencias y el contrato de replay determinista.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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:

Lenguaje dominante
Python
Estrellas
58
Forks
32
Merge medio
1 d 6 h
PR fusionados (30 d)
80

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de aws/aws-durable-execution-sdk-python

Todos los issues de aws/aws-durable-execution-sdk-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.