You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/core/parallel.md
+57-46Lines changed: 57 additions & 46 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,9 @@
27
27
28
28
**Branch** - An individual function within a parallel operation. Each branch executes independently and can succeed or fail without affecting other branches.
29
29
30
-
**BatchResult** - The result object returned by parallel operations, containing successful results, failed results, and execution metadata.
30
+
**BatchResult** - The result object returned by parallel operations. It includes a `BatchItem` for each branch plus counts and completion metadata.
31
+
32
+
**BatchItem** - A per-branch entry with `index`, `status`, `result`, and `error` (if failed).
31
33
32
34
**Completion strategy** - Configuration that determines when a parallel operation completes (e.g., all successful, first successful, all completed).
33
35
@@ -55,7 +57,7 @@ Use parallel operations to:
55
57
-**Independent execution** - Each branch runs in its own child context with isolated state
56
58
-**Flexible completion** - Configure when the operation completes (all successful, first successful, etc.)
57
59
-**Error isolation** - One branch failing doesn't automatically fail others
58
-
-**Result collection** - Automatic collection of successful and failed results
60
+
-**Result collection** - Automatic collection of per-branch status, results, and errors
59
61
-**Concurrency control** - Limit maximum concurrent branches with `max_concurrency`
60
62
-**Checkpointing** - Results are checkpointed as branches complete
-`throw_if_error()`- Raises the first branch error, ifany
124
127
125
-
**Raises:**Exceptions are captured per branch and included in`failed_results`. The parallel operation itself doesn't raise unless all branches fail (depending on completion configuration).
128
+
**Raises:**Branch exceptions are captured inthe `BatchResult`. Call `throw_if_error()`if you want to raisethe first failure.
Use `result.succeeded()`, `result.failed()`, or`result.started()`for`BatchItem` lists filtered by status, and`result.throw_if_error()` to raise the first failure when you want exceptions instead of error objects.
-`CompletionConfig.all_successful()`- Requires all branches to succeed (default)
305
312
-`CompletionConfig.first_successful()`- Completes when any branch succeeds
306
-
-`CompletionConfig.all_completed()`-Waits forallbranches to complete regardless of success/failure
313
+
-`CompletionConfig.all_completed()`-Completes when branches finish; check `started_count`if completion criteria are met early
307
314
- Custom configuration with specific success/failure thresholds
308
315
309
316
```python
@@ -320,6 +327,8 @@ config = ParallelConfig(
320
327
321
328
**item_serdes**- Custom serialization for individual branch results. If not provided, uses JSON serialization.
322
329
330
+
Note: If completion criteria are met early (min success reached or failure tolerance exceeded), unfinished branches are marked `STARTED`in`result.all`and counted in`started_count`.
**Important:** Even though branches execute concurrently and may complete inany order, the SDK preserves the original order in the results list. This makes it easy to correlate results with inputs.
621
632
622
633
### Handling partial results
623
634
624
-
When some branches fail, `successful_results` only contains results from successful branches, but the order is still preserved relative to the input:
635
+
When some branches fail, `succeeded()` only contains results from successful branches, but the order is still preserved relative to the input:
625
636
626
637
```python
627
638
# If function at index 1 fails:
@@ -672,8 +683,8 @@ Choose the right completion strategy for your use case:
672
683
- Strict consistency requirements
673
684
674
685
**all_completed()**- Best for:
675
-
-Best-effort operations
676
-
- Collecting partial results
686
+
-Workflows where you want to observe branch outcomes end-to-end
687
+
- Collecting partial results (pair with tolerated failure settings if failures are expected)
677
688
- Logging or monitoring tasks
678
689
679
690
### Checkpointing overhead
@@ -729,7 +740,7 @@ A: No, branch functions must be synchronous. If you need to call async code, use
729
740
730
741
**Q: What happens ifall branches fail?**
731
742
732
-
A: The behavior depends on your completion configuration. With `all_successful()`, the operation fails. With `all_completed()`, you get a `BatchResult`withall failuresin`failed_results`.
743
+
A: The behavior depends on your completion configuration. You always get a `BatchResult`; inspect `get_errors()`or`failed()` to see failures, or call `throw_if_error()` to raise the first error.
0 commit comments