Use atomic writes for session restore #2529
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Recently, there's been a couple reports of Min losing session restore data unexpectedly (#2519, #2527, also #2503 and https://discord.com/channels/764269005195968512/764544014259060797/1305916870473547776 which may or may not be related).
I'm not currently sure what the cause(s) of these are, as nothing has changed recently in this code, but this PR updates session restore to write the file atomically, which should mean that we can always re-launch with a valid restore file even if something goes wrong during the write. I also added some metrics collection for write failures and restoration failures to try to understand if this is a widespread issue.
It's possible that this is slower than a standard write, which mainly impacts shutdown times, as we write the file synchronously before exiting. In my very limited experimentation it doesn't seem to be too bad though.
If this resolves the issue, we could also extend this approach to the settings file, about which we've also had similar reports. That data is less critical though, so the performance vs reliability tradeoff may be different there.