[Feature]: Support incremental composition of parallel operations

Ouverte
  • Quelque chose ne va pas ?
#614 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@SravyaPeri y travaille déjà.

Depuis le 13/8/2026.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
Calme
Stack technique
java, python
Domaine
backend-api-design, distributed-systems

Piste de recherche

Commencez par l'API Python DurableContext.parallel actuelle dans packages/aws-durable-execution-sdk-python/src/aws_durable_execution_sdk_python/types.py, puis comparez le cycle de vie exposé par ParallelDurableFuture de Java. Spécifiez dans un RFC la sémantique de l'enregistrement, de l'achèvement, de la validation du replay et de l'achèvement anticipé avant l'implémentation. Le travail est terminé lorsqu'une conception d'API additive approuvée préserve l'API existante basée sur les séquences et le contrat de replay déterministe.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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:

Langage dominant
Python
Étoiles
58
Forks
32
Merge moyen
1 j 6 h
PR mergées (30 j)
80

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de aws/aws-durable-execution-sdk-python

Toutes les issues de aws/aws-durable-execution-sdk-python

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.