-
Notifications
You must be signed in to change notification settings - Fork 596
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Weird interaction between cancelation and interruptWhen #2962
Weird interaction between cancelation and interruptWhen #2962
Conversation
Weird interaction between cancelation and interruptWhen
I believe that the `.as(canceledError)` is safe as our `fa.attempt` was canceled which means that cancelation is unmasked in this scope and hence `F.canceled.as(canceledError) <-> F.canceled`. This matches the behaviour in `Scope#interruptibleEval` when there is no interrupt context and it binds `fa.attempt` directly
Preserves previous behaviour
deferred.get should not error or be canceled
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice find+fix!
case Left(other) => Left(other) | ||
F.raceOutcome(deferred.get, fa.attempt).flatMap { | ||
case Right(oc) => | ||
oc.embed(F.canceled.as(canceledError)).map(_.leftMap(Outcome.Errored(_))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a nit, maybe we can write this with oc.fold(...)
to save the two separate ops?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yep, good call 👍 Will fix tomorrow
Fix hanging when combining
Stream.eval(F.canceled)
andinterruptWhen
.I believe that the
.as(canceledError)
is safe as ourfa.attempt
was canceled which means that cancelation is unmasked in this scope and henceF.canceled.as(canceledError) <-> F.canceled
. This matches the behaviour inScope#interruptibleEval
when there is no interrupt context and it bindsfa.attempt
directly.