You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 7, 2024. It is now read-only.
In the FullStockTickerService example that uses bidirectional streaming it feels to me like the use of the AwaitCancellation() method that creates a task that completes when the CancellationToken of the ServerCallContext is cancelled is unneccesary and has just been caried over from the example with the single stream without much thought.
Why not just await the HandleActions() method directly there since its task also completes when the same CancellationToken is cancelled?
Furthermore, if an exception is thrown in the HandleActions() method for some reason in a more complex example it will not cancel the CancellationToken and the program will stop reading new actions but the program will not stop because it will continue waiting for the token to be cancelled at the call to AwaitCancellation(). This seems rather dangerous to me in a real world scenario.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In the FullStockTickerService example that uses bidirectional streaming it feels to me like the use of the
AwaitCancellation()
method that creates a task that completes when theCancellationToken
of theServerCallContext
is cancelled is unneccesary and has just been caried over from the example with the single stream without much thought.Why not just await the
HandleActions()
method directly there since its task also completes when the sameCancellationToken
is cancelled?Furthermore, if an exception is thrown in the
HandleActions()
method for some reason in a more complex example it will not cancel theCancellationToken
and the program will stop reading new actions but the program will not stop because it will continue waiting for the token to be cancelled at the call toAwaitCancellation()
. This seems rather dangerous to me in a real world scenario.The text was updated successfully, but these errors were encountered: