Search Issue Tracker
Third Party Issue
Third Party Issue in 2023.1.X
Votes
0
Found in
2020.3.37f1
2021.3.6f1
2022.1.9f1
2022.2.0b1
2023.1.0a3
Issue ID
UUM-8830
Regression
No
Task's state is not updated outside of the scope of the EventHandler when it's called asynchronously
Reproduction steps:
1. Open the user's attached project
2. Enter Play mode
3. Observe the Console window
Expected result: No errors are logged in the Console window. The messages log "Result now set to 42:::RanToCompletion" and "Test task status :::: RanToCompletion" because the state is the same in and outside of the EventHandler
Actual result: A "Failed..." error is logged because the Task.Wait has timed out. "Result now set to 42:::RanToCompletion" and "Test task status :::: WaitingForActivation" messages are logged because the state of the task is different outside of the EventHandler
Reproducible with: 2020.3.37f1, 2021.3.6f1, 2022.1.9f1, 2022.2.0b1, 2023.1.0a3
Reproducible on: macOS 12.4 (Intel)
Note: Replacing testMethodAsync() with testMethod() in line 22 of Consumer.cs will change the call to a synchronous one, so Task.Wait will not time out and the state will be the same
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Error “Shader error in 'YSCloudCover': call to 'tex3D' is ambiguous at Assets/YSCloudCoverText.shader(606) (on d3d11)“ is present when compiling tex3D shader with DXC
- Placeholder asset is not loaded with Advertisement Legacy sample when using the latest version of the package
- Addressables content build fails but the Player build is successful when building a development build
- Out-of-bounds memory access with multiple CanvasRenderers under a Canvas when using Mesh API
- Inspector tries to access file after it was deleted when the file was locked in Inspector window
Resolution Note:
The user code actually contains a deadlock preventing the task to run to completion:
Consumer::Start() is a synchronous method that blocks the main thread (`var success = testTask.Wait(10000);` itself blocks the main thread for 10s). As "testMethodAsync" is called from the main thread, the continuations happening on every "await" expression is scheduled on the main thread, so until the "Start" method returns, testMethodAsync cannot complete.
A workaround, would be to implement the Start method as an asynchronous method and await the task instead of blocking.
Resolution Note (2023.1.X):
The user code actually contains a deadlock preventing the task to run to completion:
Consumer::Start() is a synchronous method that blocks the main thread (`var success = testTask.Wait(10000);` itself blocks the main thread for 10s). As "testMethodAsync" is called from the main thread, the continuations happening on every "await" expression is scheduled on the main thread, so until the "Start" method returns, testMethodAsync cannot complete.
A workaround, would be to implement the Start method as an asynchronous method and await the task instead of blocking.