-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Description
Preflight Checklist
- I have searched the issue tracker for an issue that matches the one I want to file, without success.
- I am not looking for support or already pursued the available support channels without success.
- I have checked the troubleshooting guide for my problem, without success.
Viper Version
1.21
Go Version
1.25
Config Source
Files
Format
JSON
Repl.it link
No response
Code reproducing the issue
Expected Behavior
If WatchConfig() encounters an error during setup of some kind that is non-recoverable, it should panic in a way that the caller can recover from if desired and output in the manner they choose instead of calling slog and os.Exit.
Actual Behavior
located here
watcher, err := fsnotify.NewWatcher()
if err != nil {
v.logger.Error(fmt.Sprintf("failed to create watcher: %s", err))
os.Exit(1)
}Depending on configuration of slog, nothing gets output, causing confusion as to why the program just silently failed.
Steps To Reproduce
No response
Additional Information
This bug has caused me literal hours of frustration as my configs would not load in docker ~50% of the time in my CI pipeline, meaning the program would fail 50% of the time in my pipeline. (half a dozen yesterday alone trying to tackle why my programs just randomly failed, let alone the dozens of hours of CI retry-time and having to babysit the jobs).
I believe the full solution would be to move the initialization that happens in the first WatchConfig goroutine out of being a goroutine.
At this point, the initWG wait group is having no effect other than to unnecessarily increase the complexity of the system.