Thanks for the report. It's a bit hard to find context on what that error means, but there's a bit of detail in this chromium issue. It sounds like this happens if the browser JS engine doesn't respond for 30 seconds. I'm not certain, but perhaps this can happen if your laptop goes to sleep while in the middle of a transaction. When it wakes up, 30 seconds will have elapsed, and the transaction will fail.

Unfortunately I'm not sure if there's an easy fix for this. We don't currently have a way to re-try transactions in a sane manner. cc/ @schmidt-sebastian in case this is something we could accommodate with our multi-tab work somehow (since we'll need to start gracefully handle when transactions fail due to loss of the primary tab lease).

I'll also ping the Chrome folks to see if they have any ideas.

FYI- I've opened a bug against Chrome here: https://bugs.chromium.org/p/chromium/issues/detail?id=855624

If you were willing and so inclined, creating an IndexedDb-only repro that they could use to reproduce the issue would probably make it more actionable. Else, I'm hoping they can figure it out from the description.

Thanks for your follow up.
Will try to prepare a repo soon.

@mikelehen
Any chance that we can get error on save on this case?
I mean through error to catch on (set, update, add) operations
Thanks

@mohshraim Hrm. I think that may be challenging to do in a straightforward and useful way since:

1. The SDK writes to persistence in a bunch of places and it's not always possible / straightforward to match the persistence write back to a corresponding user operation.
2. Once a persistence write fails, the SDK's in-memory state will be out-of-sync with the on-disk state and we can't reliably perform any more operations. So we would need to fail any subsequent user operations as well (and in fact, I think we do this already. Once this error occurs, any subsequent set() or onSnapshot() calls will probably throw the "AsyncQueue is already failed" exception that you got in your screenshot).

We could perhaps add a bit of extra logic to make sure that when we hit one of these errors, all existing set() calls are rejected and all existing onSnapshot() listeners are canceled. But the SDK will still be in an unusable state until you refresh the page, so I'm not sure if this is actually useful.

Hi
Please, we need a way to can react to this errors, and in this case let the user refresh the page.
I'm getting this errors to often and the chrome thread says the plan on working it for next year

The only way I have to detect this issue is to open the console, something the end users will not do

I'm getting this error on FIRESTORE (5.5.0)

Thanks

It's not pretty, but you could always register a global error handler (https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror).

Beyond that, these aren't meant to be recoverable errors (the SDK is in an inconsistent state) and so it's not something we're likely to expose in a public API.

If you have any extra details about how to reproduce the issue or how often it occurs for your users, I'd encourage you to chime in on the chromium issue. Ultimately, we need a fix from them. :-/

Thank you for your help, let me tell you about my case (if I find a way to reproduce it i'll go to the chromium thread):

It mainly appears when I have a big dataset loaded (in my case a collection listener with around 4 thousand small docs)

When I change the tab to other pages, and then I return to the page, usually an update is triggered, the onSnapshot function puts the data in a class and takes 2 or 3 seconds to complete (I manually ignore multiple concurrent calls), if another part of the page trys to read a doc from the cache, I usually get this error.

But that is not always the case, mostly is when the page is open for a long time, more than 2 o 3 hours, and you came and go from the page, that can trigger the problem too, but is always random.

How should I detect the error is from the SDK and not other type of error? should I check for the text of the error?

Thanks

Yeah, to detect the error, you would need to just check the text. It's not foolproof, but it's better than nothing hopefully.

Your first repro sounds pretty curious to me. The SDK only performs one action at a time, and so there shouldn't be any concurrent calls and I'm not sure what "if another part of the page trys to read a doc from the cache" means exactly.

So if you can narrow down that repro at all, that would be helpful.

I'm using angular
I have a service that is accessed from all the page. There I init a onSnapshot call, convert the data to a class, and send the array to a rxjs BehaviourSubject.next()

If an update is triggered the function is called and the update function runs and calls the next with the new array.

This goes on the background, If a user clicks on a component that views that document and a read to firestore (with the cache option) is performed to the same collection.

Most of the time it works, but sometimes it doesn't and when I check the logs, everithing is in red with this error.

Interesting. If you find a repro (ideally as simplified as possible, even without angular would be nice), we can take a look and see if anything looks amiss.

I'm going to close this issue, since I think it really needs to be addressed in chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=855624). If anybody can find a way to reproduce it, that would probably help expedite a fix.

@mikelehen

For me this really very rare case that occur once every 1 month... and hard to reproduce on my case..
It is will be big plus if we can return any error on update, set operation when this case faced by SDK..

Thanks for follow up.

@mikelehen
I found a way to reproduce and get the same error... its not the same case when laptop go to sleep but get the same error.

Steps:
init firestore with persistence enabled
make realtime listener query
stop the code in developer tool; wait 20-40 seconds and continue run code..
pingo error appear :)

Thanks @mohshraim! I added a note to https://bugs.chromium.org/p/chromium/issues/detail?id=855624

@mohshraim were you able to find a workaround for this?

@sengoontoh
sorry for late delay
generally i add try catch on saving docs using frestore..
this will prevent client from unknown stop of system... and if i catch mentioned error notify user that application will reload after 2-5 seconds