Is this still necessary? Anonymous user info, and null user info, will both fail !!oldUserID check

why isn't this shouldClearData(currentLoggedInUserID, currentDBUserID)?
why was this change made? before if currentLoggedInUserID && currentLoggedInUserID === currentDBUserID && errorGettingUserID this code would also run

It looks like in the past, resetUserSpecificState would execute when going from a logged-out state (no currentUserInfo) to a logged-in state (non-anonymous currentUserInfo). After your changes, this no longer happens. Was this change intentional? Is it consistent with behavior on the SQLite side?

Yeah, it isn't. Going to remove it.

Yes, it is intentional. The idea behind resetting the state is to protect the user's data. If a user was logged in and becomes logged out or a new user becomes logged in - we should clear the data. But if a user wasn't logged in and becomes logged in, we can assume that they were able to access the data from the store - so there's no point in clearing it.

On the SQLite side, we're doing something similar - if in the DB userID is null we don't clear the DB. The consistency is enforced by using shouldClearData in both places.

why isn't this shouldClearData(currentLoggedInUserID, currentDBUserID)?

The logic is indeed the same, but it is a coincidence. We can decide to modify shouldClearData function without updating this place. In this place, we're simply making sure that the owner of the DB is correctly updated.

why was this change made?

Now it is clear what's the purpose of this code. The intention wasn't to directly replicate the previous behavior, but instead create something obviously correct. Both versions try to achieve the same thing - making sure that the userID in the DB is updated when necessary.

before if currentLoggedInUserID && currentLoggedInUserID === currentDBUserID && errorGettingUserID this code would also run

When currentLoggedInUserID === currentDBUserID then this code is a no-op, and we don't have to run it.

Makes sense, thanks for explaining

Should we have made the same change to SQLiteDataHandler on native? Now it appears that the logic is inconsistent

We can follow up in D11670 actually