Search Issue Tracker
Third Party Issue
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
- Mono Windows Builds don't produce full log callstacks when generating logs
- AssetBundles fail to load when running in Built Players for Mobile Devices
- UI elements with text gets bigger and grey when Player window is moved to another screen with different resolution
- System name accepts multiline text but crops it on confirmation, duplicates input, and shrinks the field when empty
- UI element scale and position are wrong in project build when DRS is changed with HDR and Software Dynamic Resolution enabled
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.