feat!: add cancellation tokens #184
Conversation
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. |
Signed-off-by: Austin Drenski <austin@austindrenski.io>
austindrenski
force-pushed
the
async-cancellation-plumbing
branch
from
0dc319f
to
b7b770a
Compare
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
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 |
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 <austin@austindrenski.io> Signed-off-by: Todd Baert <todd.baert@dynatrace.com> Co-authored-by: Austin Drenski <austin@austindrenski.io> Co-authored-by: André Silva <2493377+askpt@users.noreply.github.com> Co-authored-by: Ryan Lamb <4955475+kinyoklion@users.noreply.github.com>
See: #154 (comment)