-
Notifications
You must be signed in to change notification settings - Fork 645
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
Throw CancellationError
instead of returning nil
during early cancellation.
#2401
Throw CancellationError
instead of returning nil
during early cancellation.
#2401
Conversation
…terator.next()` is cancelled instead of returning `nil`
…ation. This also deprecates the generic `Failure` type of `NIOThrowingAsyncSequenceProducer` and it now must always be `any Swift.Error`. Otherwise we couldn’t throw `CancellationError` on cancellation and again need to return nil. For backward compatibility we will still return nil if `Failure` is not `any Swift.Error` or `CancellationError`.
# Conflicts: # Sources/NIOCore/AsyncSequences/NIOThrowingAsyncSequenceProducer.swift
Sources/NIOCore/AsyncSequences/NIOThrowingAsyncSequenceProducer.swift
Outdated
Show resolved
Hide resolved
Sources/NIOCore/AsyncSequences/NIOThrowingAsyncSequenceProducer.swift
Outdated
Show resolved
Hide resolved
Sources/NIOCore/AsyncSequences/NIOThrowingAsyncSequenceProducer.swift
Outdated
Show resolved
Hide resolved
Sources/NIOCore/AsyncSequences/NIOThrowingAsyncSequenceProducer.swift
Outdated
Show resolved
Hide resolved
…r.swift Co-authored-by: George Barnett <gbarnett@apple.com>
…r.swift Co-authored-by: George Barnett <gbarnett@apple.com>
…r.swift Co-authored-by: George Barnett <gbarnett@apple.com>
…r.swift Co-authored-by: George Barnett <gbarnett@apple.com>
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.
We clearly have no tests for the typed error case, as we haven't had to deprecate anything. Can you add tests for that case that confirm we appropriately do not throw CancellationError
in them, thereby testing the new function?
Sources/NIOCore/AsyncSequences/NIOThrowingAsyncSequenceProducer.swift
Outdated
Show resolved
Hide resolved
…adoba/swift-nio into dn-throw-cancellation-error-on-cancel
backPressureStrategy: backPressureStrategy, | ||
delegate: delegate | ||
) | ||
let sequence = new.sequence |
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.
Can we make sure to use withExtendedLifetime
to preserve the producer side? That'll help me be confident that this code doesn't have this effect because the producer is being dropped.
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.
Added in c7863f6
We can't wrap the whole thing in withExtendedLifetime
because we call an async method and the closure withExtendedLifetime
takes isn't async. (another use case for reasync)
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.
Thanks. I'm happy with the patch as written. More broadly, if you ever want to say "I need a value to live to this point in the code", the idiom has ended up becoming to just write withExtendedLifetime(theValue) { }
. Your version works too, so I'm happy with this as-is, but just an FYI for the future that you could have simply written that at the bottom of the file.
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.
Ah, nice. Thank you!
Motivation:
Follow up PR for #2399
We currently still return
nil
if the currentTask
is canceled before the first call toNIOThrowingAsyncSequenceProducer.AsyncIterator.next()
but it should throwCancellationError
too.In addition, the generic
Failure
type turns out to be a problem. Just throwing aCancellationError
without checking thatFailure
type isany Swift.Error
orCancellationError
introduced a type safety violation as we throw an unrelated type.Modifications:
CancellationError
on eager cancellationFailure
type ofNIOThrowingAsyncSequenceProducer
. It now must always beany Swift.Error
. For backward compatibility we will still return nil ifFailure
is notany Swift.Error
orCancellationError
.Result:
CancellationError
is now correctly thrown instead of returningnil
on eager cancelation. GenericFailure
type is deprecated.