Problem
Onyx write paths that flow through retryOperation (mergeCollectionWithPatches, multiSetWithRetry, setCollectionWithRetry, partialSetCollection) had two pre-existing bugs: (1) a brand-new key was silently downgraded from Storage.multiSet to Storage.multiMerge on retry, and (2) keysChanged/keyChanged re-fired on every retry attempt, double-notifying Onyx.connect({waitForCollectionCallback: true}) subscribers. This could cause stale UI or duplicate subscriber invocations when IndexedDB writes fail and retries kick in.
Solution
Bump react-native-onyx from 3.0.85 to 3.0.86, which includes react-native-onyx#792. Each refactored write path now splits into an outer orchestrator (cache update, subscriber notification, and storage prep — called once) and a file-private write helper that retryOperation re-enters, ensuring the cache stays consistent and subscribers fire exactly once per logical write.
PR
#94449
Issue Owner
Current Issue Owner: @mallenexpensify
Problem
Onyx write paths that flow through
retryOperation(mergeCollectionWithPatches,multiSetWithRetry,setCollectionWithRetry,partialSetCollection) had two pre-existing bugs: (1) a brand-new key was silently downgraded fromStorage.multiSettoStorage.multiMergeon retry, and (2)keysChanged/keyChangedre-fired on every retry attempt, double-notifyingOnyx.connect({waitForCollectionCallback: true})subscribers. This could cause stale UI or duplicate subscriber invocations when IndexedDB writes fail and retries kick in.Solution
Bump react-native-onyx from 3.0.85 to 3.0.86, which includes react-native-onyx#792. Each refactored write path now splits into an outer orchestrator (cache update, subscriber notification, and storage prep — called once) and a file-private write helper that
retryOperationre-enters, ensuring the cache stays consistent and subscribers fire exactly once per logical write.PR
#94449
Issue Owner
Current Issue Owner: @mallenexpensify