Skip to content

Commit

Permalink
Update ADRs
Browse files Browse the repository at this point in the history
  • Loading branch information
adamw committed Aug 6, 2024
1 parent 344166d commit 3dff76f
Show file tree
Hide file tree
Showing 2 changed files with 3 additions and 6 deletions.
4 changes: 2 additions & 2 deletions doc/adr/0001-error-propagation-in-channels.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ If there are multiple forks running in parallel, there are two possible scenario
cancelling any forks that are operating in the background. Any unused channels can then be garbage-collected.
2. If you choose not to re-throw, the forks running in parallel would be allowed to complete normally (unless the containing scope is finished for another reason).

Internally, for the built-in `Source` operators, we took the latter approach, i.e. we chose not to re-throw and let the parrallel forks complete normally.
Internally, for the built-in `Source` operators, we took the latter approach, i.e. we chose not to re-throw and let the parallel forks complete normally.
However, we keep in mind that they might not be able to send to downstream channel anymore - since the downstream might already be closed by the failing fork.

### Example
Expand All @@ -49,7 +49,7 @@ def mapParUnordered[U](parallelism: Int)(f: T => U)(using Ox, StageCapacity): So
try
c.send(f(t)) // (4)
s.release()
catch case t: Throwable => c.error(t) // (5)
catch case e: Exception => c.error(t) // (5)
}
true
}
Expand Down
5 changes: 1 addition & 4 deletions doc/adr/0003-why-source-operators-do-not-throw.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,9 +8,6 @@ Revisiting ADR #1, what should happen when an error is encountered when processi

## Decision

In addition to what's mentioned in ADR #1, operators don't throw, but propagate, because:

* we might be in a non-supervised scope, so the errors would disappear silently (as the intermediate forks aren't visible to the end user, and are not supervised in this scenario)
* we want to allow throw-free coding style. When errors are propagated, on error every daemon operator thread shuts down, and we end the scope gracefully.
In addition to what's mentioned in ADR #1, operators don't throw, but propagate, because we want to allow throw-free coding style. When errors are propagated, on error every daemon operator thread shuts down, and we end the scope gracefully.

Additionally, we assume that data only flows downstream - and this includes errors.

0 comments on commit 3dff76f

Please sign in to comment.