Tensions in Practice: Early failure notice in tension with collecting every outcome¶
Asynchronous results · two independent producers
Two independent tasks start together. A fails at time 1; B finishes successfully at time 3. A combined promise can reject as soon as any required result fails, or wait to return a record of both outcomes. That choice changes what its consumer learns and when. In this example it does not cancel either task: B keeps running after the early rejection.
Report failure promptly
Tell a consumer immediately when an all-required result can no longer succeed.
Collect every outcome
Deliver both successes and failures together, including useful partial results.
Why these aims pull against each other
A result contract can settle before all producers finish. Waiting for an outcome record retains visibility of partial results but delays the combined report.
Choose an arrangement to see what changes and what remains difficult.
Finite illustrative comparisons. Text states carry the meaning; color is not a measured score or universal preference.
What this choice protects
What it costs
When it fits
Compare the arrangements
Reject early
The all-required composite rejects at time 1 and stays rejected. B continues to its own successful result.
| Task A | Task B | Composite | |
|---|---|---|---|
| Start | Pending | Pending | Pending |
| Time 1 | Rejected | Running | Rejected |
| Time 3 | Rejected | Value B | Still rejected |
- What it protects
- A consumer needing both values can react to the known failure without waiting for B.
- What it costs
- The composite does not provide B’s later value, and its settlement does not clean up B’s work or side effects.
- When it fits
- Any failed component makes the combined value unusable, and sibling completion or cancellation has a separate explicit policy.
Illustration note: Times are stipulated. No cancellation authority is attached to this composite; rejecting a placeholder is not a task-lifetime operation.
Collect outcomes
Wrap each task’s success or failure as an outcome, then return both records after the last task settles.
| Task A | Task B | Composite | |
|---|---|---|---|
| Start | Pending | Pending | Pending |
| Time 1 | Rejected | Running | Pending |
| Time 3 | Rejected | Value B | Both outcomes |
- What it protects
- The consumer receives A’s error and B’s useful value in one complete report.
- What it costs
- The composite stays pending until time 3; a producer that never settles would keep this contract waiting unless separately bounded.
- When it fits
- Partial results matter and the consumer can tolerate waiting for all outcomes.
Illustration note: This all-outcomes contract is an editorial composition of settled outcome records, not a claim that every promise library uses this name or supplies it automatically.
What this illustration does—and does not—establish
Future or Promise Future Or Promise: Composition Algebra versus Failure Propagation supplies failure propagation and Future Or Promise: Producer Authority versus Consumer Expectation separates cancellation authority. The outcome-record composition is an explicitly specified alternative.
- The two tasks have identical execution and failure behavior in both tables.
- This comparison concerns result settlement, not cancellation, structured task ownership, retries, or cleanup.
- A collected rejection remains a failure of that task; returning its record does not convert the task itself to success.
Source entries
Future Or Promise
Future Or Promise: Composition Algebra versus Failure Propagation supplies the conflict examined here.
Composition Algebra versus Failure Propagation
Futures compose under then/all/race into dependency graphs, but the composition operators carry implicit failure semantics — all rejects on the first sub-rejection, race ignores the losers.
Producer Authority versus Consumer Expectation
Diagnostic: separate who may fulfill, reject, timeout, and cancel into distinct named authorities, and check each expectation against the producer's actual rights.