-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Improved reliability of Task.GetResultOrDefault #3410
Improved reliability of Task.GetResultOrDefault #3410
Conversation
Thanks Sergio0694 for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌 |
@Sergio0694 were there any test cases hitting this code? Feel like we should add one for the scenario you described that was broken before but fixed now? |
@michael-hawker Isaw a crash because of this in the sample app, a EDIT: found it! 🎉 |
CI failed for out of memory error (unrelated). Hopefully #3408 does the trick... 🤞 |
Manually added the "needs attention 👋" tag as #3408 is now merged into this branch and the CI is passing 🚀 |
Follow up for #3229
PR Type
What kind of change does this PR introduce?
What is the current behavior?
The
Task.GetResultOrDefault
can returnnull
on some runtimes, if the inputTask
(Task<T>
) instance is actually a subclass.Eg. on UWP that type is sometimes some internal
AsyncValueBox<T>
type, which fails with that method (it returnsnull
).What is the new behavior?
The extension is now more reliable and works with
Task<T>
-inherited type.PR Checklist
Please check if your PR fulfills the following requirements:
Pull Request has been submitted to the documentation repository instructions. Link:Sample in sample app has been added / updated (for bug fixes / features)Icon has been created (if new sample) following the Thumbnail Style Guide and templates