feat!: add cancellation tokens #184
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Jan 17, 2024
austindrenski
force-pushed
the
async-cancellation-plumbing
branch
from
ef28ff5 to
0dc319f
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #184 +/- ##
=========================================
+ Coverage 0 94.73% +94.73%
=========================================
Files 0 23 +23
Lines 0 931 +931
Branches 0 93 +93
=========================================
+ Hits 0 882 +882
- Misses 0 29 +29
- Partials 0 20 +20 ☔ View full report in Codecov by Sentry. |
10 tasks
Signed-off-by: Austin Drenski <[email protected]>
austindrenski
force-pushed
the
async-cancellation-plumbing
branch
from
0dc319f to
b7b770a
Compare
benjiro
approved these changes
Feb 15, 2024
There was a problem hiding this comment.
I'm fine with this, probably my bad for missing putting the CTs in the first place. Thanks for fixing it up, makes sense to support this specially if the library is being consumed in a web app.
Async suffix is a well understood convention and mentioned many times in the originally docs. I'm good with adding it, breaking change is minimal.
Nice work
toddbaert
requested changes
Feb 20, 2024
There was a problem hiding this comment.
I definitely want to do this, but I want to collect a few breaking changes and create an issue for them all... then we can perhaps maintain a v2 branch for a while, and merge it all at once when we're ready to release.
I'll create that issue to discuss, but blocking for now. Let me know if you disagree.
|
We should maybe update the conventional commit tag to have an exclamation point. Makes it easy to see that it needs to be held off. |
toddbaert
changed the title
|
I'm assigning this to myself. Next week I'll work on cleaning it up, which will hopefully also help me understand how we can best use these tokens in terms of how they integrate with the rest of the SDK's semantics.
Did this, thanks @kinyoklion |
|
I've started on this and #185 |
|
Closing and continuing with #268 |
toddbaert
added a commit
that referenced
this pull request
Jun 17, 2024
This PR is a combination of #184 and #185. Changes include: - adding cancellation tokens - in all cases where async operations include side-effects (`setProviderAsync`, `InitializeAsync`, I've specified in the in-line doc that the cancellation token's purpose is to cancel such side-effects - so setting a provider and canceling that operation still results in that provider's being set, but async side-effect should be cancelled. I'm interested in feedback here, I think we need to consider the semantics around this... I suppose the alternative would be to always ensure any state changes only occur after async side-effects, if they weren't cancelled beforehand. - adding "Async" suffix to all async methods - remove deprecated sync `SetProvider` methods - Using `ValueTask` for hook methods - I've decided against converting all `Tasks` to `ValueTasks`, from the [official .NET docs](https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.valuetask?view=net-8.0): > the default choice for any asynchronous method that does not return a result should be to return a [Task](https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.task?view=net-8.0). Only if performance analysis proves it worthwhile should a ValueTask be used instead of a [Task](https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.task?view=net-8.0). - I think for hooks, `ValueTask` especially makes sense since often hooks are synchronous, in fact async hooks are probably the less likely variant. - I've kept the resolver methods as `Task`, but there could be an argument for making them `ValueTask`, since some providers resolve asynchronously. - I'm still a bit dubious on the entire idea of `ValueTask`, so I'm really interested in feedback here - associated test updates UPDATE: After chewing on this for a night, I'm starting to feel: - We should simply remove cancellation tokens from Init/Shutdown. We can always add them later, which would be non-breaking. I think the value is low and the complexity is potentially high. - ValueTask is only a good idea for hooks, because: - Hooks will very often be synchronous under the hood - We (SDK authors) await the hooks, not consumer code, so we can be careful of the potential pitfalls of ValueTask. I think everywhere else we should stick to Task. --------- Signed-off-by: Austin Drenski <[email protected]> Signed-off-by: Todd Baert <[email protected]> Co-authored-by: Austin Drenski <[email protected]> Co-authored-by: André Silva <[email protected]> Co-authored-by: Ryan Lamb <[email protected]>
arttonoyan
pushed a commit
to arttonoyan/dotnet-sdk
that referenced
this pull request
Nov 17, 2024
This PR is a combination of open-feature#184 and open-feature#185. Changes include: - adding cancellation tokens - in all cases where async operations include side-effects (`setProviderAsync`, `InitializeAsync`, I've specified in the in-line doc that the cancellation token's purpose is to cancel such side-effects - so setting a provider and canceling that operation still results in that provider's being set, but async side-effect should be cancelled. I'm interested in feedback here, I think we need to consider the semantics around this... I suppose the alternative would be to always ensure any state changes only occur after async side-effects, if they weren't cancelled beforehand. - adding "Async" suffix to all async methods - remove deprecated sync `SetProvider` methods - Using `ValueTask` for hook methods - I've decided against converting all `Tasks` to `ValueTasks`, from the [official .NET docs](https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.valuetask?view=net-8.0): > the default choice for any asynchronous method that does not return a result should be to return a [Task](https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.task?view=net-8.0). Only if performance analysis proves it worthwhile should a ValueTask be used instead of a [Task](https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.task?view=net-8.0). - I think for hooks, `ValueTask` especially makes sense since often hooks are synchronous, in fact async hooks are probably the less likely variant. - I've kept the resolver methods as `Task`, but there could be an argument for making them `ValueTask`, since some providers resolve asynchronously. - I'm still a bit dubious on the entire idea of `ValueTask`, so I'm really interested in feedback here - associated test updates UPDATE: After chewing on this for a night, I'm starting to feel: - We should simply remove cancellation tokens from Init/Shutdown. We can always add them later, which would be non-breaking. I think the value is low and the complexity is potentially high. - ValueTask is only a good idea for hooks, because: - Hooks will very often be synchronous under the hood - We (SDK authors) await the hooks, not consumer code, so we can be careful of the potential pitfalls of ValueTask. I think everywhere else we should stick to Task. --------- Signed-off-by: Austin Drenski <[email protected]> Signed-off-by: Todd Baert <[email protected]> Co-authored-by: Austin Drenski <[email protected]> Co-authored-by: André Silva <[email protected]> Co-authored-by: Ryan Lamb <[email protected]> Signed-off-by: Artyom Tonoyan <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See: #154 (comment)