Direct Firestore "add", "update", etc. calls fails when signed in

I’ve been updating a project of mine (which uses react-redux-firebase) from firebase to firestore.

So far so good. I’ve got the sign in system working, and have the data querying code working fine. (as far as I’ve tested anyway)

I’m now trying to reimplement the data saving/storing code. Because I prefer the direct route for storing data rather than the redux “action” system, I’m using code like this:

store.firebase.firestore().collection("users").add({
    first: "Ada",
    last: "Lovelace",
    born: 1815
}).then(()=>console.log("Done")).catch(err=>console.log("Error: " + err))

The code above works perfectly when I am not signed in. When I’m signed in, however, the code snippet does nothing. It just returns a promise which never completes.

If I sign back out, it starts working again. If I sign back in, it stops working.

Any idea what could be causing these direct calls to fail?

[Venryx]

I went ahead and submitted a bug-report. (at https://firebase.google.com/support/contact/bugs-features)

It’s possible the issue only comes up in particular circumstances, however. (it’s a bit hard to believe they let an issue that large pass testing)

Can someone check if the issue occurs in your project as well – update failing for non-existent paths, but giving no error or warning message? (and furthermore, blocking later requests if 10+ of these failed calls occur)

Just run this code:

// for me, these calls silently fail and fill the 10-request buffer
for (var i = 0; i < 15; i++) {
    store.firebase.firestore().doc("nonexistent/path").update({name: "Ada"})
    .then(()=>console.log("Done"))
    .catch(err=>console.log("Error: " + err));
}

// then when this valid request runs, the buffer is already full, so it also just silently fails
store.firebase.firestore().collection("users").add({name: "Ada"})
.then(()=>console.log("Valid call was not blocked!"))
.catch(err=>console.log("Error: " + err));

If the issue occurs in your project as well, then the “Valid call was not blocked!” message will never show.

Anyway, I’ll close the issue since it appears to not be a problem with redux-firestore specifically.

[Venryx]

I appear to have found the cause:

firestoreDB.doc(`userExtras/${userID}`).update({
	permissionGroups: {basic: true, verified: true, mod: false, admin: false},
	joinDate: Date.now(),
});

The code above was set to run as soon as the user logged in (for the first time). However, it used the “update” function instead of the “set” function. Using firebase, the same code worked, even if the userExtra/USERID path did not exist yet; however, this version seems to fail if the path does not exist.

Therefore, the calls would get sent to firestore, but firestore either wouldn’t respond, or the response was not handled correctly, causing the request to never get removed from the request-buffer (in Network dev-tools, it appears the request was sent and a suitable response; however, the breakpoints were never hit for the code that processes the responses – even as far back as I could trace the standard stack-trace).

Since the request-buffer has a max length of 10, it would then get full and block further calls.

Everything works as expected when the code is changed to use “set”: (with “merge” set to true)

firestoreDB.doc(`userExtras/${userID}`).set({
	permissionGroups: {basic: true, verified: true, mod: false, admin: false},
	joinDate: Date.now(),
}, {merge: true});

To me, this appears to be a bug in Firestore’s web-client. If the “update” call fails to run because the path does not exist, the client should raise some sort of warning or error. Or at the very least, remove the call from the buffer, so that later calls can pass through.