Skip to content
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

Merged

Conversation

Sergio0694
Copy link
Member

Follow up for #3229

PR Type

What kind of change does this PR introduce?

  • Bugfix

What is the current behavior?

The Task.GetResultOrDefault can return null on some runtimes, if the input Task (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 returns null).

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:

  • Tested code with current supported SDKs
  • Pull Request has been submitted to the documentation repository instructions. Link:
  • Sample in sample app has been added / updated (for bug fixes / features)
  • Tests for the changes have been added (for bug fixes / features) (if applicable)
  • Header has been added to all new source files (run build/UpdateHeaders.bat)
  • Contains NO breaking changes

@Sergio0694 Sergio0694 added bug 🐛 An unexpected issue that highlights incorrect behavior improvements ✨ .NET Components which are .NET based (non UWP specific) labels Aug 4, 2020
@Sergio0694 Sergio0694 added this to the 7.0 milestone Aug 4, 2020
@ghost
Copy link

ghost commented Aug 4, 2020

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 🙌

@ghost ghost requested review from michael-hawker, azchohfi and Kyaa-dost August 4, 2020 12:59
@michael-hawker
Copy link
Member

@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?

@Sergio0694
Copy link
Member Author

Sergio0694 commented Aug 4, 2020

@michael-hawker Isaw a crash because of this in the sample app, a Task<T> was actually reported as being some weird AsyncValueBox<T>-something that I literally can't find anywhere in the source of CoreCLR or in the docs. Will see if I can replicate that in the tests and/or if I can find more info about this thing 😄

EDIT: found it! 🎉
It's System.Runtime.CompilerServices.AsyncTaskMethodBuilder<TResult>.AsyncStateMachineBox<TStateMachine> 🙈

@Sergio0694
Copy link
Member Author

CI failed for out of memory error (unrelated). Hopefully #3408 does the trick... 🤞

@Sergio0694
Copy link
Member Author

Sergio0694 commented Aug 8, 2020

Manually added the "needs attention 👋" tag as #3408 is now merged into this branch and the CI is passing 🚀

@azchohfi azchohfi merged commit f8b78a3 into CommunityToolkit:master Aug 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 An unexpected issue that highlights incorrect behavior improvements ✨ needs attention 👋 .NET Components which are .NET based (non UWP specific)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants