Repository navigation
Use async ChangeToken.OnChange overload in FileConfigurationProvider - #130492
Merged
Merged
Conversation
Replace the blocking Thread.Sleep in the reload callback with an awaited Task.Delay, using the new async Func<Task> overload of ChangeToken.OnChange (dotnet#69099). This avoids blocking a thread for the duration of the reload delay. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 059bf1b8-31e2-4608-a038-210880f90d06
Contributor
|
Tagging subscribers to this area: @dotnet/area-extensions-configuration |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates FileConfigurationProvider’s file-change reload callback to use the async ChangeToken.OnChange overload and replace a blocking Thread.Sleep debounce with an awaited Task.Delay, aiming to avoid tying up a thread during the reload delay.
Changes:
- Replace
Thread.Sleep(Source.ReloadDelay)withawait Task.Delay(Source.ReloadDelay).ConfigureAwait(false)inside the reload callback. - Switch the callback passed to
ChangeToken.OnChangeto anasynclambda (binding to theFunc<Task>overload). - Update
usingdirectives accordingly (System.Threading→System.Threading.Tasks).
rosebyte
approved these changes
Jul 17, 2026
Member
Author
|
/ba-g failure is #130678 and is unrelated |
svick
added a commit
that referenced
this pull request
Jul 21, 2026
…tems (#130627) Fixes #121475. ## Problem When a Generic Host app lives on a file system that can't be watched — e.g. a WSL path (`\\wsl.localhost\...`) accessed via `dotnet` from Windows, or other mounted/network drives — it crashes with a `StackOverflowException` after a while. On such a file system, `FileSystemWatcher` keeps failing to start and raises the same `Error` every time it's enabled. In `PhysicalFilesWatcher.OnError` this cancels the change tokens, which fires the `ChangeToken.OnChange` registration set up by `FileConfigurationProvider` (and similar consumers). That registration's producer re-creates a token via `CreateFileChangeToken`, which re-enables the watcher, which raises the same `Error` again — an unbounded cancel -> re-register -> re-enable -> error cycle that recurses until the stack overflows. ## Fix `PhysicalFilesWatcher.OnError` now distinguishes persistent failures from recoverable ones: - The **first** occurrence of an error is reported as before. - An **identical recurrence** — same exception type and OS error code (`Win32Exception.NativeErrorCode`, otherwise `HResult`) — with **no change delivered in between** is **suppressed** (the tokens aren't cancelled), which breaks the loop. - `InternalBufferOverflowException` (the watcher is alive but dropped events, so consumers must rescan) and `DirectoryNotFoundException` (the watched directory was deleted/moved) are **always** reported and reset the detection. - Any **delivered change** resets the remembered error, so a transient error that later recovers isn't mistaken for a persistent one. This is detection-only: on a genuinely unwatchable file system the app no longer crashes, but file-change-based reload is simply inactive there (matching the documented behavior that `FileSystemWatcher` "is ineffective in some scenarios such as mounted drives", whose remedy is `DOTNET_USE_POLLING_FILE_WATCHER`). Automatically falling back to polling is probably undesirable. ## Relationship to #130492 #130492 (switching `FileConfigurationProvider` to the async `ChangeToken.OnChange` overload) already works around the reported crash: awaiting `Task.Delay(ReloadDelay)` unwinds the stack between iterations, so the recursion becomes a (slow) async loop instead of growing the stack. That mitigates the `StackOverflowException` for the default `ReloadDelay` (250 ms), but it doesn't address the underlying churn (the watcher is still re-enabled and re-errors on a loop), and it's defeated by `ReloadDelay == 0` (`Task.Delay(0)` completes synchronously, restoring the synchronous recursion). This PR fixes the root cause in `PhysicalFilesWatcher`, independent of the consumer's overload or reload delay. ## Known limitation macOS raises buffer overflow as a plain `IOException(SR.FSW_BufferOverflow)` (with `HResult` set to the FSEvents flags), not `InternalBufferOverflowException` like Windows/Linux. So the "always report" carve-out doesn't recognize it, and a sustained macOS overflow with no delivered change in between could be suppressed. A clean follow-up is to make the macOS `FileSystemWatcher` raise `InternalBufferOverflowException` for consistency: #130637. ## Tests Added tests in `PhysicalFilesWatcherTests` that drive `OnError` via `MockFileSystemWatcher.CallOnError`: - an identical error recurrence is suppressed (covering both `Win32Exception`/`NativeErrorCode` and `IOException`/`HResult`); - a different error code is still reported; - `InternalBufferOverflowException` and `DirectoryNotFoundException` are always reported; - a delivered change resets detection so the same error is reported again; - an `Error` with no exception is always reported. > [!NOTE] > This pull request was created by GitHub Copilot. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Uses the new async (
Func<Task>) overload ofChangeToken.OnChange(see #69099) inFileConfigurationProvider.The reload callback previously blocked a thread for the whole reload delay via
Thread.Sleep(Source.ReloadDelay). It nowawaitsTask.Delay(...)instead, so no thread is blocked while waiting out the debounce delay before reloading:Why only this call site
The other in-repo callers of
ChangeToken.OnChange(ConfigurationRoot,ConfigurationManager,OptionsMonitor) invoke short, synchronous, non-blocking consumers (RaiseChanged/InvokeChanged) and gain nothing from the async overload, so they are intentionally left unchanged.A closely related change is at dotnet/aspnetcore#67732.
Note
This PR description was generated by GitHub Copilot.