Skip to content

IndexedDB Recovery for Limbo documents #3039

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
May 13, 2020

Conversation

schmidt-sebastian
Copy link
Contributor

Addresses #2755

@google-oss-bot
Copy link
Contributor

google-oss-bot commented May 8, 2020

Binary Size Report

Affected SDKs

  • @firebase/firestore

    Type Base (54c7872) Head (6ed84f4) Diff
    browser 249 kB 249 kB +64 B (+0.0%)
    esm2017 194 kB 194 kB +4 B (+0.0%)
    main 490 kB 490 kB +29 B (+0.0%)
    module 247 kB 247 kB +64 B (+0.0%)
  • @firebase/firestore/memory

    Type Base (54c7872) Head (6ed84f4) Diff
    browser 190 kB 190 kB +64 B (+0.0%)
    esm2017 148 kB 148 kB +4 B (+0.0%)
    main 366 kB 366 kB +29 B (+0.0%)
    module 188 kB 188 kB +64 B (+0.0%)
  • firebase

    Type Base (54c7872) Head (6ed84f4) Diff
    firebase-firestore.js 288 kB 288 kB +64 B (+0.0%)
    firebase-firestore.memory.js 230 kB 230 kB +64 B (+0.0%)
    firebase.js 821 kB 821 kB +64 B (+0.0%)

Test Logs

Copy link
Contributor

@wilhuff wilhuff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with a note.


await this.applyRemoteEvent(event);

// Since this query failed, we won't want to manually unlisten to it.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It took me a moment to think I understand why this ordering is better. If I'm understanding correctly, the idea is to avoid removing the limbo target until we successfully apply the remote event because if we fail, we'll shut down the listen stream, and then when we resume we'll resend the limbo targets, right?

A comment to this effect could help future readers understand why the watch start/stop lifecycle makes this a reasonable choice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. If we can't update the cache, it is better for the documents to stay in limbo rather than go out of limbo temporarily. I modified the existing comment to say:

// Since this query failed, we won't want to manually unlisten to it.
// We only remove it from bookkeeping after we successfully applied the
// RemoteEvent. If `applyRemoteEvent()` throws, we want to re-listen to 
// this query when the RemoteStore restarts the Watch stream, which should 
// re-trigger the target failure.

@wilhuff wilhuff assigned schmidt-sebastian and unassigned wilhuff May 13, 2020
@schmidt-sebastian schmidt-sebastian merged commit 8e2fd91 into master May 13, 2020
@firebase firebase locked and limited conversation to collaborators Jun 13, 2020
@schmidt-sebastian schmidt-sebastian deleted the mrschmidt/limborecovery branch November 9, 2020 22:39
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants