dotnet watch: Mac Catalyst hot-reload agent WebSocket drops before the first edit; updates fail but watch reports "changes applied"

[horatiuvlad]

Summary

On Mac Catalyst, dotnet watch run's hot-reload agent connects and negotiates full capabilities at app startup, then its WebSocket connection drops before the first edit arrives. Every subsequent update batch fails with No active WebSocket connection from the client, the session gives up (Further changes won't be applied to this process) — and dotnet watch still reports C# and Razor changes applied in 835ms, so the failure is invisible unless running with --verbose.

Two distinct problems:

1. the agent's WebSocket connection does not survive from startup to the first edit, and there is no reconnect;
2. dotnet watch reports success after every update in the batch failed.

Environment

macos-latest GitHub runner (arm64), .NET SDK 10.0.3xx, maui workload set 10.0.302 (i.e. including dotnet/macios#24664, so StartupHookSupport defaults to true in Debug and the agent genuinely loads). App: scaffolded MAUI-based Mac Catalyst app, net10.0-maccatalyst, Debug, DOTNET_USE_POLLING_FILE_WATCHER=1.

Launch is worked around via an explicit _AppBundleName override (without it dotnet run cannot start a Catalyst app at all when ApplicationTitle != AssemblyName; filed as dotnet/macios#26318).

Observed (verbose log, single session)

At startup:

dotnet watch : Hot reload session started.
dotnet watch : [App (net10.0-maccatalyst)] WebSocket client connected
dotnet watch : [App (net10.0-maccatalyst)] Capabilities: 'Baseline AddMethodToExistingType AddStaticFieldToExistingType NewTypeDefinition ChangeCustomAttributes AddInstanceFieldToExistingType GenericAddMethodToExistingType GenericUpdateMethod UpdateParameters GenericAddFieldToExistingType AddExplicitInterfaceImplementation'.
dotnet watch : [App (net10.0-maccatalyst)] WebSocket client disconnected

On the first (method-body-only) edit, ~1 minute later:

dotnet watch : File change: Update '.../MainPage.cs'.
dotnet watch : Hot reload capabilities: ... (full set)
dotnet watch : [App (net10.0-maccatalyst)] Sending update batch #0
dotnet watch : [App (net10.0-maccatalyst)] Update batch #0 failed with error: No active WebSocket connection from the client.
dotnet watch : [App (net10.0-maccatalyst)] Update batch #0 exception stack trace:    at Microsoft.DotNet.HotReload.WebSocketClientTransport.RequestHandler.WriteAsync(...)
dotnet watch : [App (net10.0-maccatalyst)] Further changes won't be applied to this process.
dotnet watch : [App (net10.0-maccatalyst)] Disposing agent websocket transport
dotnet watch : C# and Razor changes applied in 835ms.

Verified at runtime that nothing was applied: the edit injected a Console.WriteLine into a method the app executes every 10 seconds; the new output never appeared over 180s, and the process was not restarted either. Reproduced identically across two independent sessions (with and without an explicit MtouchInterpreter=all, which is the Debug default anyway).

Expected

Either the agent connection stays up for the lifetime of the process (or reconnects), or — failing that — dotnet watch reports the update as failed and falls back to its restart path, instead of printing changes applied.

The false success seems the more severe half: without --verbose the user sees a healthy hot-reload session that silently applies nothing.

[horatiuvlad]

Re-verified with the one workaround from the original report removed, in case it was a confound. It isn't.

Fresh run on a clean macos-latest runner with an unpinned workload (dotnet workload install maui, no --skip-manifest-update): workload version 10.0.302, maui manifest 10.0.20/10.0.100, Microsoft.MacCatalyst.Sdk.net10.0_26.5 26.5.10301. Same scaffolded Catalyst app, same harness, --property:RunWithOpen=false, and no _AppBundleName override:

app launched after ~21s
dotnet watch : [VidraSmoke.Host (net10.0-maccatalyst)] WebSocket client connected
dotnet watch : [VidraSmoke.Host (net10.0-maccatalyst)] WebSocket client disconnected
--- VERDICT (~180s): edited-output=0, ready before=1 after=1 ---
dotnet watch : [VidraSmoke.Host (net10.0-maccatalyst)] Update batch #0 failed with error: No active WebSocket connection from the client.
dotnet watch : [VidraSmoke.Host (net10.0-maccatalyst)] Further changes won't be applied to this process.
dotnet watch : C# and Razor changes applied in 806ms.

Identical with --property:MtouchInterpreter=all (second probe in the same run: launched ~15s, connect → disconnect, batch #0 fails, changes applied in 1317ms, no runtime effect and no restart).

One correction to my own environment section: "Launch is worked around via an explicit _AppBundleName override (without it dotnet run cannot start a Catalyst app at all...)" is stale. dotnet/macios#26318 is fixed from Microsoft.MacCatalyst.Sdk.net10.0_26.2 onwards, so on a current workload the app launches with no override — which is exactly why the run above could drop it. The WebSocket behaviour is unchanged either way.

[horatiuvlad]

More data, and one correction to the report: this is intermittent, not deterministic.

Eight dotnet watch run sessions on macos-latest, current workload (workload version 10.0.302, Microsoft.MacCatalyst.Sdk.net10.0_26.5 26.5.10301), scaffolded MAUI Catalyst app, --property:RunWithOpen=false, no other overrides:

SDK	build state	agent socket after 30s idle, before any edit	first edit
10.0.301	fresh checkout	connected	delta applied in place (same PID)
10.0.301	rm -rf bin obj + rebuild	dropped	batch #0 fails, nothing applied
10.0.302	fresh checkout	dropped	batch #0 fails, nothing applied
10.0.302	rm -rf bin obj + rebuild	connected	delta applied in place (same PID)
10.0.302	×4 more, default verbosity	dropped in all four	nothing applied

So the delta channel works about a quarter of the time here, and when it fails the socket drops while the session is idle, before the first edit — the update failure is a consequence, not the trigger. It correlates with neither the SDK version nor the freshness of the build output (it failed on a freshly wiped tree and succeeded on an untouched one), which rules out stale incremental output as the cause.

The second half of the report — that dotnet watch reports success anyway — holds in every failing session, and matters more than it first appears because it is visible at default verbosity:

dotnet watch : [App (net10.0-maccatalyst)] Further changes won't be applied to this process.
dotnet watch : C# and Razor changes applied in 1866ms.

That is the whole of what a user sees: a warning that the process is now inert, immediately followed by a success line for the edit that was just dropped. (Update batch #0 failed with error: No active WebSocket connection from the client is LogDebug, so it only appears under --verbose.)

Practical consequence for tooling, in case it is useful to others hitting this: the Further changes won't be applied to this process. warning is LogWarning in DefaultHotReloadClient, so it is machine-detectable without --verbose. Our CLI now watches for it and falls back to a rebuild-and-relaunch loop when it appears — 4/4 dead sessions printed it, so the detection is reliable even though the underlying flake is not.

[tmat]

@jonathanpeppers Wanna take a look into why the connection's dropping?