elsa-workflows / elsa-workflows/elsa-foundation

Handle child faults and parent-child cancellation

Open
#680 0 comments 0 reactions 0 assignees View on GitHub
ready-for-agent
Dominant language
C#
Stars
5
Forks
1
Avg merge
3h 52m
Merged PRs (30d)
212

Description

## Parent

#674

## What to build

Complete non-success child completion and cancellation semantics for DispatchWorkflow. A waited child that faults or is cancelled must complete the dispatch activity with an explicit safe result and outcome rather than faulting the activity itself. Parent cancellation must atomically cancel a pending unmaterialized dispatch or idempotently request cancellation of a materialized child when propagation is enabled, while opt-out and detached behavior remain stable.

Covers parent user stories 12–13, 16–17, 20–24, and 53.

## Acceptance criteria

- [ ] A faulted child completes DispatchWorkflow with terminal status and outcome Faulted without automatically faulting the parent activity.
- [ ] A cancelled child completes DispatchWorkflow with terminal status and outcome Cancelled.
- [ ] Faulted and cancelled results contain no partial child outputs and expose only safe diagnostic summaries and incident identifiers.
- [ ] Unconnected fault and cancellation outcomes follow normal graph semantics without implicit escalation.
- [ ] CancelChildOnParentCancellation defaults to true and applies only in wait mode.
- [ ] Parent cancellation before child materialization atomically cancels the pending dispatch so later delivery cannot start the child.
- [ ] Parent cancellation after child materialization sends an idempotent child cancellation request.
- [ ] Setting cancellation propagation to false allows the waited child to continue independently.
- [ ] Fire-and-forget children remain independent of ordinary parent completion and cancellation.
- [ ] Race and duplicate-delivery tests cover cancellation before and after child materialization, terminal notification, and parent cancellation.

## Blocked by

- #679

Contributor guide

No contributing guide indexed for this repository

Research direction

After #679 is complete, start by tracing DispatchWorkflow and its parent-child completion and cancellation paths. Run or add the race and duplicate-delivery tests described in the acceptance criteria, covering cancellation before and after child materialization and terminal notification. Done means faulted or cancelled children produce safe terminal outcomes without unintended parent faulting, while propagation and fire-and-forget behavior remain stable.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
backend, distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.