-
Notifications
You must be signed in to change notification settings - Fork 557
Description
This issue was triggeded by the now closed PR #719 as I feel this is something worth discussing/changing.
Currently the filestore panics in a number of situations:
Open
if the folder does not exist and can not be created- If a file cannot be written
- If a file cannot be read (but not if the data is read successfully but is corrupted)
One situation where this can lead to a panic is (copied from the PR):
- The program was launched with Root rights when the broker was unavailable.
- The message was saved for subsequent sending. With Root rights.
- When the program was launched with limited rights, we get a panic.
I believe it can be argued that a panic is appropriate because a non-working file system can lead to a loss of messages. However it can also be argued that a panic is excessive and the system should log the issue and resume.
Personally I'm reluctant to remove all of the panics. If there is an issue that impacts message integrity then panicing (in the absence of an option to log an error) is probably appropriate - especially soon after startup (as this means its more likely the user will spot/correct the issue). The V5 client takes a different approach, it checks that it can read/write from the folder at startup and then just logs any errors after that (felt this was a pragmatic solution). Unfortunately the current V3 client API does not have provision to return errors.
Thoughts?