Status Update
No update yet.
Comments
se...@google.com
I am able to also reproduce issue #1 now; I've committed a change to the sample project that sets enableMultiInstanceInvalidation() on the DB and adjusts the timing a bit more. After running it for 15 minutes or so I am seeing multiple skipped updates.
My production app uses enableMultiInstanceInvalidation() as well, so this may be a significant factor.
se...@google.com
Any thoughts on this one? I mean, it makes JournalMode.TRUNCATE largely useless, unless one has a penchant for random app misbehaviors. I'd like to keep using TRUNCATE, as it avoids certain headaches from WRITE_AHEAD_LOGGING.
il...@google.com
To be clear, "batching" does not take care of the missed invalidation notifications. Updates for a table may be spaced hours apart, and in my production app about 5% of notifications are lost, meaning that the user does not see the update until the next one comes in, which may be hours later. It's a chatroom feature, where reliable, timely updates are important.
Also, not setting enableMultiInstanceInvalidation() does not fix the issue, it only changes the timing; notifications go missing regardless of whether I include one process or multiple.
ap...@google.com
Hi - Sorry, we haven't had the chance to investigate this. I know this might be a lot to ask and thanks for giving us a sample app, but have you try adding a transaction in the invalidation tracker? You can check out Room's source code here:
Also what headaches are you trying to avoid from WAL mode?
Description
The keys() method in SavedStateHandle will always include keys for values set via the set() method, but it doesn't include the keys associated with a SavedStateProvider set via setSavedStateProvider() until after state is saved. If you wanted to remove all of the SavedStateProviders by iterating through the keys, whether it would work or not would depend on if state was already saved, which is kind of inconsistent and seems like a bug.