Fix dotnet-watch Hot Reload deadlock on platforms with a startup SynchronizationContext#54131
Closed
kotlarmilos wants to merge 1 commit intodotnet:mainfrom
Closed
Fix dotnet-watch Hot Reload deadlock on platforms with a startup SynchronizationContext#54131kotlarmilos wants to merge 1 commit intodotnet:mainfrom
kotlarmilos wants to merge 1 commit intodotnet:mainfrom
Conversation
…hronizationContext Wrap the applier bootstrap in Listener.Listen in Task.Run(...) so the awaits inside InitializeAsync resume on the threadpool instead of the startup-hook thread. The previous code did a synchronous InitializeAsync(ct).GetAwaiter().GetResult() directly on the startup thread. On platforms whose .NET startup-hook thread carries a SynchronizationContext (iOS Mono and CoreCLR, Android Mono and CoreCLR), the await inside WebSocketTransport.ConnectAsync captures that SC for its continuation, and the synchronous wait blocks the only thread that could resume it. With this fix, end-to-end dotnet watch Hot Reload works across mobile on CoreCLR and Mono. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes a startup deadlock in dotnet-watch Hot Reload on platforms where the startup-hook thread has a SynchronizationContext (e.g., iOS/Android), by ensuring the initial Hot Reload agent bootstrap runs on the thread pool.
Changes:
- Replace a synchronous
InitializeAsync(...).GetResult()on the startup-hook thread withTask.Run(...).GetResult()to avoidSynchronizationContextcapture. - Add explanatory comments describing the deadlock scenario and why the thread-pool hop is required.
Show a summary per file
| File | Description |
|---|---|
| src/Dotnet.Watch/HotReloadAgent.Host/Listener.cs | Runs initial hot reload initialization on the thread pool to avoid SC-related deadlock during startup. |
Copilot's findings
- Files reviewed: 1/1 changed files
- Comments generated: 1
Comment on lines
+37
to
+43
| // block execution of the app until initial updates are applied. | ||
| // Run on the thread pool (Task.Run) so that awaits inside InitializeAsync | ||
| // do not capture the calling thread's SynchronizationContext. Otherwise, | ||
| // on platforms where the startup-hook thread has a sync context (e.g. iOS, | ||
| // Android), the synchronous wait below would deadlock when an awaited | ||
| // continuation tries to resume on the same blocked thread. | ||
| Task.Run(() => InitializeAsync(cancellationToken), cancellationToken).GetAwaiter().GetResult(); |
There was a problem hiding this comment.
The deadlock fix is important, but it isn’t currently covered by a regression test. Since the repo already has unit tests that instantiate Listener (e.g., test/Microsoft.Extensions.DotNetDeltaApplier.Tests/HotReloadClientTests.cs), consider adding a test that runs Listener.Listen from a thread with a non-null SynchronizationContext and uses a test Transport.SendAsync that performs an await (e.g., Task.Yield) to validate that initialization completes (i.e., no sync-context deadlock) within a timeout.
Member
Author
|
Fixed in #54023 |
This was referenced Apr 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR wraps the applier bootstrap in
Listener.ListeninTask.Run(...)so that the awaits insideInitializeAsyncresume on the threadpool instead of the startup-hook thread. The previous code did a synchronousInitializeAsync(ct).GetAwaiter().GetResult()directly on the startup thread. On platforms whose .NET startup-hook thread carries aSynchronizationContext(iOS Mono and CoreCLR, Android Mono and CoreCLR), theawaitinsideWebSocketTransport.ConnectAsynccaptures that SC for its continuation, and the synchronous wait blocks the only thread that could resume it.With this fix, end-to-end
dotnet watchHot Reload works across mobile on CoreCLR and Mono.