[Bug]: Unable to hot reload runtime section since file is being used by another process

[Aniruddh25]

What happened?

With dab 0.10.23, I tested hot reload of the runtime config section.

I changed the runtime.rest.path value from "/api" to "/rest".

Was expecting the route changed to a different prefix. Instead, I saw this message in the logs and the new path route couldn't be found on querying.

Version

0.10.23

What database are you using?

Azure SQL

What hosting model are you using?

Local (including CLI)

Which API approach are you accessing DAB through?

REST

Relevant log output

Loading config file from dab-config.json.
Unable to hot reload configuration file due to The process cannot access the file 'dab-config.json' because it is being used by another process.
Loading config file from dab-config.json.
Unable to hot reload configuration file due to The process cannot access the file 'dab-config.json' because it is being used by another process.
Loading config file from dab-config.json.

....

 Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3]
      Route matched with {action = "Find", controller = "Rest"}. Executing controller action with signature System.Threading.Tasks.Task`1[Microsoft.AspNetCore.Mvc.IActionResult] Find(System.String) on controller Azure.DataApiBuilder.Service.Controllers.RestController (Azure.DataApiBuilder.Service).
fail: Azure.DataApiBuilder.Service.Controllers.RestController[0]
      b16e74da-4022-4880-a2c6-50e1cce3c8c6 Error handling REST request.
      Azure.DataApiBuilder.Service.Exceptions.DataApiBuilderException: Invalid Path for route: rest/Book.
         at Azure.DataApiBuilder.Core.Services.RestService.GetRouteAfterPathBase(String route)
         at Azure.DataApiBuilder.Service.Controllers.RestController.HandleOperation(String route, EntityActionOperation operationType)

Code of Conduct

• I agree to follow this project's Code of Conduct

[seantleonard]

This task needs resolution in .12rc milestone. not moving.

[aaronburtle]

Some additional context as to what is happening here:

This is expected due to the behavior of the file watcher that we are using in conjunction with file editors that take write locks while they have the config file open. When we start file watching, our file watcher will constantly be reading the file to check for changes. This is fine and what we expect to be happening. When a file editor goes to make a change to the file, it will take a write lock, which makes the file unable to be read by the file watcher. That results in the error messaging that we see. Certain file editors, such as Visual Studio Code, seem to hold a write lock the entire time that they have the file open. Other file editors such as Notepad++ only hold a write lock while they are actually making changes and saving them to the file. In the latter case, we will still see this error messaging the way that we currently have our file watcher configured, as it will constantly be trying to read, and then when the editor takes a write lock, it will throw the error saying another process has the file open. Then once the editor releases the write lock, our file watcher will pick up the changes and go to work.

As hot reloading is finalized we need to determine the kind of error messaging that we want to relay to the user in this case. If the editor they are using is constantly holding the write lock, as appears to be the case for Visual Studio Code, this error message is useful, as it communicates back to the user exactly what is happening; another process has the file open and as such we can not hot reload. In the case of editors that only grab the write lock to save the file, the error is transient and not useful.

In the meantime, while hot reload is being finalized and is not available as a feature, we will have the file watcher not be in a state where it is constantly reading the file. This will eliminate this error messaging until such time that we decide Hot Reload is ready, and at which point we will implement the error messaging that makes the most sense.

[aaronburtle]

Closing this issue as it is currently fixed from the change in #2108