Skip to content

Make esm-amd-loader dynamic require 404 test not flaky.#511

Merged
aomarks merged 4 commits intomasterfrom
flaky-esm-404-test
Jun 13, 2018
Merged

Make esm-amd-loader dynamic require 404 test not flaky.#511
aomarks merged 4 commits intomasterfrom
flaky-esm-404-test

Conversation

@aomarks
Copy link
Member

@aomarks aomarks commented Jun 12, 2018

Previously this test used a 1 second timeout to wait to see how many times the error callback was called, which was flaky on CI. Now we capture 404 errors and check callback calls after two 404s.

Fixes #507

(Note first commit is just clang formatting).

aomarks added 2 commits June 12, 2018 13:16
Previously this test used a 1 second timeout to wait to see how many
times the error callback was called, which was flaky on CI. Now we
capture 404 errors and check callback calls after two 404s.

Fixes #507
@aomarks aomarks requested a review from rictic June 12, 2018 20:28
@aomarks aomarks changed the title Make esm-amd-loader dynamic require 404 not flaky. Make esm-amd-loader dynamic require 404 test not flaky. Jun 12, 2018
window.addEventListener('error', on404, true);

function on404() {
if (++num404s === 2) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Prefer inert conditionals.

num404s++;
if (num404s === 2) {
  ...

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

let num404s = 0;
let numCallbackCalls = 0;

window.addEventListener('error', on404, true);
Copy link
Contributor

Choose a reason for hiding this comment

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

Hm, I don't think this is the expected behavior. require should not throw a global error, it should only call the failure callback shouldn't it?

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, is this the browser doing this? Emitting a window error?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, you can capture the browser network errors by adding the capture phase listener (the true).

['./not-found-a.js', './not-found-b.js'],
() => assert.fail(),
() => numErrors++);
() => numCallbackCalls++);
Copy link
Contributor

Choose a reason for hiding this comment

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

Hm, what we really want to do is wait for the first error callback, and consider the test a success if the error callback isn't called again within the next little while (i.e. using setTimeout).

That should be non-flaky.

Copy link
Member Author

Choose a reason for hiding this comment

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

IIUC that would be more error prone (since network latency between the two fetches could cause the test to incorrectly pass) and slower (since we have to wait for the timeout).

Copy link
Member Author

Choose a reason for hiding this comment

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

I did need to add a tick to let the error handlers get called though. Seems reliably green on sauce now, will see what CI says.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants