Settings can be pre-read through the new storage backend, skipping re-parsing when unchanged.
A settings primer only runs when a v5 storage backend is configured, so it is inert otherwise.
What's wrong with this entry?
A new primer reads settings.json through the storage backend whenever settings are invalidated, hashing the bytes so unchanged content is not re-parsed, and seeds the result into the settings store. It only runs when a session has a v5 storage backend configured, so it is inert otherwise.
- Files over the size cap, missing files, and backend errors fall back to the ordinary raw-file read, with a log line.
- After a fixed number of consecutive failures the primer switches itself off for the rest of the process.
settingsPrime: user settings seeded
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.234
Global config file watching can move onto the storage backend
Both mention json storage backend
-
v2.1.223
Compare-and-swap retry helper for versioned storage keys
Both mention storage backend
-
v2.1.223
Daemon lock and auto-update lock gained storage-backend implementations
Both mention storage backend