Skip to content

Fix racy promises in SpecTestRunner #2693

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 5 commits into from
Mar 9, 2020
Merged

Fix racy promises in SpecTestRunner #2693

merged 5 commits into from
Mar 9, 2020

Conversation

thebrianchen
Copy link

@thebrianchen thebrianchen commented Feb 28, 2020

Context: An update to tslib (link) changed the promise resolution order. We previously had multiple race conditions in the SpecTestRunner that happened to resolve in the correct order, but now break. Although we drain the AsyncQueue after each step, operations scheduled onto the AQ as part of the step run after the drain() call with the tslib update, as opposed to running before drain() previously.

This PR makes the SpecTestRunner drain until the AQ is empty, which ensures that the SpecTestRunner is in a consistent state before moving onto the next step.

@thebrianchen thebrianchen changed the title Fix promises in Firestore spec tests Fix racy promises in SpecTestRunner Mar 2, 2020
@thebrianchen thebrianchen assigned wilhuff and unassigned thebrianchen Mar 2, 2020
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.

Pretty much LGTM.

I'm not a huge fan of the exception you're making for step.applyClientState?.primary. It seems arbitrary. What consequences would there be for not making this exception?

@wilhuff wilhuff assigned thebrianchen and unassigned wilhuff Mar 3, 2020
@thebrianchen thebrianchen requested a review from wilhuff March 4, 2020 07:25
@thebrianchen thebrianchen assigned wilhuff and unassigned thebrianchen Mar 4, 2020
@thebrianchen
Copy link
Author

thebrianchen commented Mar 4, 2020

I'm not a huge fan of the exception you're making for step.applyClientState?.primary. It seems arbitrary. What consequences would there be for not making this exception?

This multi-tab limbo documents test test fails if we don't make the exception. If we fully drain the queue after client1 steals the primary lease, limbo documents will be generated prematurely, causing unexpected active targets when validating the step.

@thebrianchen thebrianchen requested review from schmidt-sebastian and removed request for schmidt-sebastian March 4, 2020 19:01
@@ -219,6 +222,11 @@ export class AsyncQueue {
return this._isShuttingDown;
}

// Visible for testing
isEmpty(): boolean {
Copy link
Contributor

Choose a reason for hiding this comment

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

We should be able to make this private or remove it entirely.

// It should still be possible to drain the queue after it is shutting down.
return this.enqueueEvenAfterShutdown(() => Promise.resolve());
async drain(): Promise<void> {
// Operations in the queue prior to draining may have enqueued additional
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't know if this works, but if it does you could get rid of all size accounting:

let currentTail : Promise<void>;
do (
  currentTail = this.tail;
  await currentTail;
} while (currentTail !== this.tail);

Copy link
Author

Choose a reason for hiding this comment

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

done.

Copy link
Author

@thebrianchen thebrianchen left a comment

Choose a reason for hiding this comment

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

Updated to use do/while loop + new comments

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

@wilhuff wilhuff assigned thebrianchen and unassigned wilhuff Mar 9, 2020
@thebrianchen thebrianchen merged commit b427447 into master Mar 9, 2020
@thebrianchen thebrianchen deleted the bc/tslib branch March 9, 2020 16:30
@firebase firebase locked and limited conversation to collaborators Apr 9, 2020
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