Background jobs, the daemon, plugin caches and plan docs can all route through the optional storage backend.
Many state files gained storage-backend paths with filesystem fallbacks, and nothing visibly attaches a backend.
What's wrong with this entry?
A large amount of state that was read and written directly as files can now go through an optional key/value storage backend, with the file path kept as a fallback at every call site. Covered: background job state.json and adopt.json, the daemon roster.json, pty pid files, the host-managed tombstone, bridge pointer files, plugin cache and .in-use markers, plan and workshop docs, task lists, and daemon log tailing. Nothing in the source shows what attaches the backend, so whether it is used is decided elsewhere.
- UI code reaches the backend through a new React context named
storageV5; when it is undefined, every path falls back to plain filesystem access - new error text includes "adopt.json v5 write failed", "bg roster.json v5 read failed", "host-managed tombstone v5 write failed" and "[bg] v5 jobs listing failed: cursor did not advance"
[bg] v5 jobs listing failed: cursor did not advance
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.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
-
v2.1.223
Deep-link registration and cleanup sentinels can be stored as state keys
Both mention storage backend