Production having warnings about firestore backend

[jkomoros]

[2023-12-06T04:01:51.682Z]  @firebase/firestore: Firestore (10.6.0): Could not reach Cloud Firestore backend. Backend didn't respond within 10 seconds.
This typically indicates that your device does not have a healthy Internet connection at the moment. The client will operate in offline mode until it is able to successfully connect to the backend.

Shows up on any load after the first from a fresh profile.

I thought this originally was caused by the storage outage, but it persists after that.

Cards created in this state do show up on the server viewer, although the warning spooks me (and also incidentally means that suggestions don't work because the cards never get fully loaded)

[jkomoros]

See also #665.

[jkomoros]

I wonder if I crossed some loading threshold on number of cards? Things actually appear to be loaded.

Tried updating firebase, and trying without longpolling and without cache (but that triggers the original issue in #665).

Adding cards, they appear to actually be loaded and edits going to the server, so it appears the warning is erroneous? Still it's pretty spooky, it seems to warn that there could be a data loss error if you don't sync...

[jkomoros]

https://github.com/firebase/firebase-tools/issues/6162 I thought was causing this at first (because I was also running into this after a failed deploy, but that's since been cleaned up.)

[jkomoros]

It seems like there are two issues: 1) an erroneous error showing up because it takes a long time to validate the large corpus (this is a guess) and 2) a "cards not fully loaded" error that happens due to a timing error.

There's been a long-time bug where we signal expectUnpublishedCards once, but then there are three distinct unpublished cards types, and some code paths that return an empty one will bail early before reporting that they did indeed get downloaded. This is a race that is now resolving differently due to the size of the payload (I guess)

Anywhere that takes unpublished : boolean should take type CardPublishedType = 'published' | 'unpublished_all', 'unpublished_editor', and 'unpublished_author'. And then disconnectLiveUnpublishedCardsForUser should unregister if there's a need to. And updateCards() shoud take CardPublishedtype, and send an empty object if necessary... which the reducer should note there are no items and then unset the flag of that type.

[jkomoros]

I think the recent timing change broke the "make a new working notes card" flow.

Now when you hit the working notes button or use the shortcut, it creates a card, then navigates to it outside a collection, and then doesn't open it for editing. I wonder if it's the logic for selectCardsLoaded, which I noted might be overly simplified in the change.

This also triggers the #684 more often (or it's possible that was created by that issue)

[jkomoros]

Bisect confirms it was ba3f7c84cfc39f61edfbe3599c0ba91bfe92085c that broke it

removeCards and actuallyRemoveCards looks very supicious (but hasn't been touched in a long time)

The problem is in EXPECT_NEW_CARD reducer, which sets publishedCardsLoaded or unpublishedCardsLoaded directly and thus doesn't get a warning about the thing.

Perhaps logic somewher in waitForCardToExist is too quick? And audit timing of navigateToNewCard being fired

[jkomoros]

A bug: if you create a new card before the final computed state of the last edited card settles (e.g. before all new fingerprints are calculated), it seems to navigate to the new card outside the collection (and not open for editing). Some kind of race condition that didn't used to exist.