-
Notifications
You must be signed in to change notification settings - Fork 203
Reload token doesn't trigger on file deletion #433
Comments
Yeah I can repro this in a unit test, deleting files for some reason doesn't fire change notification, but writing to the file does. |
Looks like a bug in FileProviders with the watcher not firing on delete, as the following test fails, I will open an issue in FileSystems repo
|
Tracked in FileSystem issue |
Reopening this because the bug is in Configuration not FileSystem. The problem is here: Configuration/src/Microsoft.Extensions.Configuration.FileExtensions/FileConfigurationProvider.cs Line 50 in 30e59f1
The file system watches triggers on file deletion and the code highlighted above is executed (reloading the configuration). The problem is that the file doesn't exist anymore and that code fails when the configuration file is not there and it's not optional. The exception is then silently swollen by this code: https://github.com/aspnet/FileSystem/blob/98ea34e732734413da699959dd0342033de8c149/src/Microsoft.Extensions.FileProviders.Physical/PhysicalFilesWatcher.cs#L225 and the configuration provider acts like nothing has changed. This scenario probably needs a redesign. Should the configuration provider not fail if the configuration file was loaded once before (aka on reload) (aka becoming an optional source)? Should you be able to watch for files that don't exist until they show up? |
I don't think its unreasonable to require optional: true for the scenario where deleting files is supported, it looks like things work now for deleting files if optional true. This test now passes:
@divega thoughts? That said, deleting files when optional: false basically means you would have to write an empty file instead of delete to clear one source when optional is false. |
I think the code should throw if the config file is deleted when optional = false. Otherwise, you get this silent bug and you have no idea that the configuration didn't change |
Well the configuration code is already throwing but the filewatcher is swallowing the exception right? Although I'm not sure you really want uncaught exceptions coming from the filewatcher either |
Let me list the options I think we have:
Anything I am not getting right or any option I am missing? If these are the options I would be inclined to pick option 1, as my understanding is that optional: false is intended to be just a simple safeward to avoid forgetting required configuration files on deployment and turning it into a kill switch seems to take it too far. |
Okay if we change required files to only need to exist initially, that is a pretty simple fix. Sounds good to me |
I guess this is what @victorhurdugaci suggested at #433 (comment). He also made another very good point:
It seems to me that after startup, files can appear, disappear and reappear. Are we setup to handle all cases? |
We currently are at the mercy of whatever the implementation of IFileProvider.Watch does in these cases, we basically just wire up that call to get the IChangeToken, and link it to Load(). I don't think we can do much more than explicitly block some of those scenarios (but I don't think we should) |
I think it is worth understanding how it will work. E.g. if an optional file is originally missing, do we still setup the file watcher in case it shows up later? |
We setup the file watching in the ctor if ReloadOnChange is true and we have a non null FileProvider, so if the provider supports notifications on a new file, that should work today. I can add a test to verify. |
@victorhurdugaci So even though configuration reload events are firing on deletion, the unit test I wrote against the FileProvider watch apis still fails on Delete, is there something specific in the usage there that I'm doing wrong?
|
From scenario: https://github.com/aspnet/Release/issues/66
Run this app:
appsettings.json
somewhere and make some changes to the copy.appsettings.json
(notice that the token doesn't fire. expected?)appsettings.json
wasExpected: token fires because the has settings have been updated
Actual: nothing happens
The text was updated successfully, but these errors were encountered: