The problem
Throughout the CLI commands (e.g., start.go, stop.go), the code defers db.Close() and then calls os.Exit(1) on error paths. os.Exit immediately terminates the program, completely bypassing all defer statements. While SQLite is generally forgiving of unclosed connections, this is a dangerous pattern that can cause locks to persist or interrupt active operations like VACUUM.
Release version
0.8.6
Operating system
macOS
Steps to reproduce the behavior
- Trigger any error state in a command (e.g., trying to start a timer when one is already running).
- The program exits via
os.Exit(1), skipping the deferred db.Close().
Screenshots
No response
Additional context
The idiomatic Cobra fix is to use RunE instead of Run, return the errors up the chain, and allow cmd.Execute() to handle the exit codes, ensuring all defers execute normally.
The problem
Throughout the CLI commands (e.g.,
start.go,stop.go), the code defersdb.Close()and then callsos.Exit(1)on error paths.os.Exitimmediately terminates the program, completely bypassing alldeferstatements. While SQLite is generally forgiving of unclosed connections, this is a dangerous pattern that can cause locks to persist or interrupt active operations likeVACUUM.Release version
0.8.6
Operating system
macOS
Steps to reproduce the behavior
os.Exit(1), skipping the deferreddb.Close().Screenshots
No response
Additional context
The idiomatic Cobra fix is to use
RunEinstead ofRun, return the errors up the chain, and allowcmd.Execute()to handle the exit codes, ensuring all defers execute normally.