Repository navigation
Fix MacMainThreadScheduler crash when ManagedThreadId != 1 (#646) - #649
Conversation
|
validated on linux-x64, win x64, arm64. Need to finialze mac testing |
|
finished mac testing |
|
Looking to improve my understanding of the space: I understand the bug lies in the thread scheduler expecting the main thread. |
The fix here is more for non-mac platforms by removing the managed thread id =1 that is only a requirement for the mac broker. But i did add some messages and checks for mac to fail early if possible. But for all platforms, if brokered auth is not available or fails for some reason (e.g. not on main thread for mac, network issues for WAM, missing dependencies for Linux), we will try the next authentication method, which would be browser auth in this scenario. And Brokered auth is considered interactive, so it would be interactive auth regardless. |
Fixes #646 โ MacMainThreadScheduler.StartMessageLoop() throws "Message loop must be started on the main thread" when Environment.CurrentManagedThreadId is not 1, which can happen when launched via dotnet tool run or dotnet run where internal runtime threads consume thread ID 1 before Main() executes.
MSAL's MacMainThreadScheduler assumes ManagedThreadId == 1 means "main thread." This is a .NET runtime implementation detail, not a guarantee. The dotnet tool shim and certain hosting configurations cause Main() to run on a thread where this check fails.
This change proposes falling back to no longer use the MacMainThreadScheduler when the thread != 1. Windows and Linux brokers will be unaffected, but mac broker will become unavailable and fall back to browser or DCF.