Pull Request Test Coverage Report for Build 14848505876

Details

• 2 of 24 (8.33%) changed or added relevant lines in 2 files are covered.
• 6 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.1%) to 56.743%

Totals
Change from base Build 14316804349:	0.1%
Covered Lines:	31143
Relevant Lines:	54884

💛 - Coveralls

Just a side note here: I'm not super familiar with the internals of btcd, so not sure if the same applies here. But in lnd we avoid using os.Exit() because that prevents any defer cleanup statements to run (e.g. closing network or database connections, flushing stuff to disk, closing files and so on).

That's why we're using a ShutdownLogger instead, which causes the main Goroutine to initiate a clean shutdown whenever a message with the level Critical is logged.
Might be worth considering here.

Just a side note here: I'm not super familiar with the internals of btcd, so not sure if the same applies here. But in lnd we avoid using os.Exit() because that prevents any defer cleanup statements to run (e.g. closing network or database connections, flushing stuff to disk, closing files and so on).

That's why we're using a ShutdownLogger instead, which causes the main Goroutine to initiate a clean shutdown whenever a message with the level Critical is logged. Might be worth considering here.

btcd has one database that handles everything and the flush happens here:

That's a fair point and I did think about returning an error and letting the caller handle the out of disk error but ultimately thought this was the best way to handle things. The database only ever writes to the disk at the places this code change takes place and if that's full, there's nothing else to flush for the caller because anything that the caller tries to flush follows the same code path.