Skip unchanged cached subtrees when removing nested nulls

[arekm213]

Details

Every Onyx.set (and multiSet, setCollection, new members in mergeCollection) runs removeNestedNullValues over the whole value before caching and storing it. The App rewrites some large values after almost every update, for example derived values that hold one entry per report, so each write walks the entire object even when only one field changed.

Since #765, values built from the cached one keep the same object reference for every subtree that didn't change. This PR uses that:

1. Skip subtrees the cache already holds. removeNestedNullValues(value, nullFreeReference) takes the current cached value and returns any nested object that is the same reference as in the cache as is, without walking it. The cache holds it, so it has no nulls. The returned objects are exactly the same as before (same references, same values), so subscribers get the same values and notifications. setWithRetry passes the existing value, prepareKeyValuePairsForStorage passes cache.get(key).

2. Close the four paths that put nested nulls into the cache today, since step 1 relies on the cache being null-free:

   • Batched remove-then-replace merges: the replace branch in mergeObject now cleans the replacement object when shouldRemoveNestedNulls is set (lib/utils.ts).
   • Lazy storage reads: OnyxUtils.get() cleans the value read from storage before caching it (SQLite JSON_REPLACE can leave nulls). multiGet now hands out what the cache holds after cache.merge(temp), so callers and cache agree (lib/OnyxUtils.ts).
   • Web cross-tab sync: values from another tab are cleaned before cache.set (lib/Onyx.ts).
   • Onyx.clear(): default key states are cleaned before cache.set. For example the App's default for account is {errors: null, ...}, so after a clear subscribers saw an errors key that every other path omits (lib/Onyx.ts).

   On these paths subscribers now get an omitted key instead of {key: null}, the same as on every other path.

3. Dev-only guard. If a skipped subtree does hold nulls, App code mutated a cached object in place, which Onyx doesn't support. In development this logs an alert, so it is caught early. In production the check is skipped, because it would need the walk this PR removes.

Prior work: skipNullRemoval (#655, #659) was removed in #666 because the App mutated shared nested objects. This PR still removes nulls from everything that changed and only skips subtrees that are the same reference as the cache. Draft #751 removes null pruning entirely, which would change what subscribers receive. This PR doesn't.

Results (release builds, heavy test account, median before vs. after, 8 runs per variant on an iOS simulator and 6 on an Android emulator):

Scenario	iOS	Android
Setting a large object	~290 to ~265 ms (~-9%)	293 to 282 ms (-3.8%)
Each Pusher update	347 to 331 ms (-4.6%)	349 to 336 ms (-3.7%)
Incremental reconnect	~700 to ~660 ms (~-6%)	inconclusive (emulator noise)

After release, the place to look in Sentry is StartupData.Apply for ReconnectApp.

Related Issues

GH_LINK

Linked E/App PR

Automated Tests

• utilsTest.ts: removeNestedNullValues with a reference. It returns the same output as without one for any null-free reference on randomized (seeded) inputs, returns the reference itself as is, doesn't traverse shared subtrees, still removes nulls from subtrees that differ, and ignores references that aren't plain objects. Also covers the replace branch of mergeObject cleaning only when shouldRemoveNestedNulls is true.
• onyxTest.ts (null-free cache): the native replace branch and a batched remove-then-replace update, values read from storage, multiGet handing out the cleaned cached value, set and multiSet keeping cached subtrees while removing new nulls, the dev alert on a mutated shared subtree, and a randomized test that runs sequences of set, merge, multiSet, mergeCollection and update with nested nulls and checks that every cached value stays null-free.
• Full suite: 681/681 passing.

Manual Tests

1. In the App, pin Onyx to this branch and sign in with a high traffic account.
2. Use the app normally: open reports, send messages, create and edit expenses, go offline and back online, sign out and in.
3. Verify that data updates as before, that no stale or missing fields show up, and that no removeNestedNullValues skipped a cached subtree alert appears in the dev console.
4. After signing out and back in, verify that no false error indicator shows on the account (empty errors key).

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}