Forking a conversation has a second implementation for sessions stored in the newer backend.
What's wrong with this entry?
Forking a conversation has a second implementation that copies the source records forward in bounded batches through the newer storage layer, and deletes the half-written fork if anything fails partway. It runs only when the session's history is held in that backend.
- Carries over edited and moved records, and inherits a withheld-history marker as a
fork_inheritrecord. - Distinct errors for a conversation that cannot be read and one that is too long to branch.
Conversation too long to branch through storage
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