Workflow VS safe-exceptions

I was part of that debate, I remember a rather interesting point of discussion: Is the main operation "apply" or "dedup"

Apply seems to be the common notion of event sourcing: There is a function apply that takes a state an event and yields a new state. Then, starting in an init state and iteratively applying the entire event history, boom, latest state restored.

Dedup has a lot of charm though: Run and rerun your code, if that step of your code is executed for the first time (no corresponding event in the event history) execute the step and store its result as an event in the history, however, if that step of your code is executed for the second, third time (there is a corresponding event in the event history) do not execute the step and return its result from the event in the history. The Haskell Workflow Package (https://hackage.haskell.org/package/Workflow) is a good example

Temporal follows the second approach, so "proper" Event Sourcing? You be the judge :)

In case anyone is interested, there's a long discussion on this ticket. Still hoping somebody will respond to my comment.

In safe-exception and uniftio it was decided to rethrow the original exception exactly because they decided to use uninterruptibleMask, see here for details.

unliftio (and safe-exceptions) contains a very controversial choice of of using uninterruptibleMask inside its bracket. The argument for it seem to come from this issue and comes from the fact that one of the most popular resource finalizers hClose is interruptible. This is a simplification. It is interruptible only if a file handle is used concurrently. Such usage of file handles is rather odd, and it suggest wrong architecture, for example leaking file handles using concurrency. When using file handles in synchronous setting, what withFile pattern encourages, hClose will not block and thus mask is enough.