You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to hot reload we must monitor the config file for changes. This results in constant reads by the file watcher that we instantiate to do this task. However, when editing the config file, that editor will take a write-lock on the config file, resulting in the file watcher throwing errors. These errors are expected and will continue until the editor has relinquished its write lock on the config file.
Before we introduce the hot-reload feature, we must determine how we will handle these error messages.
For example, some editors will only take a write lock while saving changes made to the file. In this case, the error messaging will be limited, perhaps only a single message, and is likely to cause confusion. It might be best to ignore these limited transient errors by not recording the first small number of errors.
But it could also be the case that the editor has taken a write-lock the entire time the file is open, not just during saves. In this case a hot reload will not be possible until that editor is closed, and the error messaging will be valuable. We should maintain these error messages, perhaps by making sure we do in fact log errors beyond the first few.
Whatever the design decision, we must gracefully handle both cases so that the error messaging is consistent and clear.
In order to hot reload we must monitor the config file for changes. This results in constant reads by the file watcher that we instantiate to do this task. However, when editing the config file, that editor will take a write-lock on the config file, resulting in the file watcher throwing errors. These errors are expected and will continue until the editor has relinquished its write lock on the config file.
Before we introduce the hot-reload feature, we must determine how we will handle these error messages.
For example, some editors will only take a write lock while saving changes made to the file. In this case, the error messaging will be limited, perhaps only a single message, and is likely to cause confusion. It might be best to ignore these limited transient errors by not recording the first small number of errors.
But it could also be the case that the editor has taken a write-lock the entire time the file is open, not just during saves. In this case a hot reload will not be possible until that editor is closed, and the error messaging will be valuable. We should maintain these error messages, perhaps by making sure we do in fact log errors beyond the first few.
Whatever the design decision, we must gracefully handle both cases so that the error messaging is consistent and clear.
Related to #2064
Related to #2108
The text was updated successfully, but these errors were encountered: