Closed mochiya98 closed 4 days ago
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
@mochiya98, thank you for the self-contained repro! I ran your code for about 200 iterations, but I did not reproduce the behavior. This included some testing with a throttled network.
Can you help me by providing the following:
setLogLevel("debug")
) and provide me with debug logs or any errors in the debug log from the test iteration that runs long?This bug is very difficult to reproduce under reproducible conditions. It may be falling back to the memory cache in some condition, please check if there is a warning at the beginning:
@firebase/firestore: Firestore (10.13.1): Error using user provided cache. Falling back to memory cache: FirebaseError: [code=failed-precondition]: Failed to obtain exclusive access to the persistence layer. To allow shared access, multi-tab synchronization has to be enabled in all tabs. If you are using
experimentalForceOwningTab:true
, make sure that only one tab has persistence enabled at any given time.
important things: nothing error occouced. when the bug occurs, only the onSnapshot of the deletion of one of the two documents is returned; 45 seconds later, the onSnapshot of the other document is reflected with a delay.
[2024-09-03T16:16:59.804Z] @firebase/firestore: Firestore (10.13.1): IndexedDbPersistence Starting transaction: notifyLocalViewChanges
// nothing occouced(45 seconds) (keepalive-only)
[2024-09-03T16:17:44.745Z] @firebase/firestore: Firestore (10.13.1): WebChannelConnection RPC 'Listen' stream 0x7b073104 received: {"targetChange":{"resumeToken":"CgkIyemhrpaniAM=","readTime":"2024-09-03T16:17:44.752329Z"}}
logger.ts:117 [2024-09-03T16:17:44.745Z] @firebase/firestore: Firestore (10.13.1): IndexedDbPersistence Starting transaction: Get last remote snapshot version
Thanks for the logs, now I can also reproduce. This appears to be related to a client-side index. I don't have a root cause yet, but I do have a workaround. The workaround requires deleting any existing client side indexes and ensuring client side index auto creation is disabled for now.
// Get client side index manager
const indexManager = getPersistentCacheIndexManager(firestore);
// Required to remove any client side indexes previously created
deleteAllPersistentCacheIndexes(indexManager);
// Should not be required because CSI auto creation is disabled by default,
// but might be a good practice in case other areas of your app could
// enable CSI
disablePersistentCacheIndexAutoCreation(indexManager);
If you do need client side indexes for other collection, you could create those with the (deprecated) setIndexConfiguration(firestore, configuration).
I have tried that code. I just added that code right after initializeFirestore
in the reproduced code above, but the bug is still reproduced.
Interesting, can you confirm if there are any index configurations IndexedDB? Chrome Developer Tools > Application > Storage > IndexedDB > firestore/[DEFAULT]/yourprojectid/main > indexConfiguration.
empty.
This error message is indicating issues with using persistent single tab cache in an app that is open in multiple tabs.
@firebase/firestore: Firestore (10.13.1): Error using user provided cache. Falling back to memory cache: FirebaseError: [code=failed-precondition]: Failed to obtain exclusive access to the persistence layer. To allow shared access, multi-tab synchronization has to be enabled in all tabs. ...
The slow getDocs() call may also be related to this.
Are you able to use the multi-tab persistence manager instead of the single-tab manager?
const firestore = initializeFirestore(app, {
localCache: persistentLocalCache({
tabManager: persistentMultipleTabManager({}),
}),
});
I was only illustrating that error as a possible fallback as to why the bug is not reproduced in your environment. The bug occurs when there is no fallback and is completely unrelated. I have tried many things. This is not a usage problem, it is a bug. And I need to use a single tab manager. Because I am actually using this within SharedWorker. But don't get me wrong, this bug occurs regardless of whether it is a SharedWorker or not.
Just to be sure, I tried the persistentMultipleTabManager, but the bug still occurs. Can you please report back to us after you confirm that the bug no longer occurs in your reproduction environment?
Any update on this case? I think there's a reason why it's exactly 45 seconds.
This one has been challenging to debug due to the frequency of occurrence. I believe it is triggered by an existence filter mismatch, which uses a probabilistic data structure and may explain the random occurrence.
The reproduction that you've provided has been helpful, but it's not clear if this rapid sequence of set/create, delete, getDocs is the only time it is seen. Do you use the same rapid sequence of calls in your app, or is this only for the reproduction? If so, what is the use case for this sequence of calls?
This reproduces the actual processing flow of the product. The collection is like a singly linked list. The problem is triggered when deleting multiple items, including the last item, and then trying to add an item at the end immediately after. Waiting a few seconds will not cause problems, but the problem is that there is no way to determine how long to wait. Waiting too long is unacceptable because it detracts from the user experience. This is a serious impediment to the use of firestore in our product and we hope that the problem will be fixed.
Any update on this case? It needs to be fixed as soon as possible.
@mochiya98, We've had a handful of people look at this issue. We are trying to move it forward. But given that the issue does not appear to be widespread, and that we have to prioritize the fix among other high-priority work, I can't provide you with a timeline for a fix.
@MarkDuckworth Our product needs a fix for this. We have waited long enough. Can you fix this within a month? If not, we will give up using firestore and use another product.
Fix is in main and will be included in the next release, likely in mid-November.
Operating System
macOS Sonoma 14.4
Environment (if applicable)
Chrome 127.0.6533.100
Firebase SDK Version
10.13.1
Firebase SDK Product(s)
Firestore
Project Tooling
No-bundle (using cdn to reproduce)
Detailed Problem Description
Steps and code to reproduce issue