[go: nahoru, domu]

Skip to content
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

core(gather-runner): add PageLoadError base artifact #9236

Merged
merged 4 commits into from
Jun 21, 2019

Conversation

brendankenny
Copy link
Member
@brendankenny brendankenny commented Jun 20, 2019

for some background, see conversation (and all the links from it) starting in #8865 (comment)

In this PR

This proposal is to disconnect pageLoadError from artifact errors:

  • add PageLoadError as a base artifact, populated if there was an error for that gathering run, otherwise null
  • artifacts will be undefined in the pass that had the pageLoadError (just like all the artifacts from passes after that one, since we bail on gathering after a pageLoadError after core: bail on gathering if we have a failure in the first pass #8866/core(gather-runner): convert PAGE_HUNG to non-fatal runtimeError #9121).
  • as a result, audits that depend on those artifacts will move from "Required x gatherer encountered an error" errors to "Required x gatherer did not run" errors, which is arguably more correct (for artifacts collected in afterPass) and doesn't suggest to the user that the issue lies in the gatherer when there was really a runtimeError they should look into

This gives us a clear and unambiguous place to mark that there was an error in the page load, which makes artifacts easier to understand as well (no more combing all artifacts to be sure there wasn't a pageLoadError in some pass).

Current behavior

When a pageLoadError occurs, it's communicated back to Runner as a bunch of artifacts from that bad pass set to that page load error. This shows up in the LHR at the audit level ("Required x gatherer encountered an error") and then runner loops over all the artifacts, and if it finds one marked as a runtime error it puts it in the lhr.runtimeError slot.

In the HTML report, the errors are displayed in similar positions (in each audit and at the top).

So, pageLoadError -> error artifact(s) -> lhr.runtimeError/errors audit result(s)

As a result, whether or not a runtime error is visible in the end LHR--even fundamental page load issues--is a function of which gatherers are run. Even more weirdly, if filtering using --only-audits, runtime error visibility is a function of which audits are run, since the gatherers that might have passed on the pageLoadError could get filtered out. This is why we had to have an audit that uses a non-trace artifact in the errors smoke test so that the runtimeError is actually seen and can be tested against.


// And it bubbled up to the runtimeError.
expect(lhr.runtimeError.code).toEqual(NO_FCP.code);
expect(lhr.runtimeError.message).toBeDisplayString(/Something .*\(NO_FCP\)/);
Copy link
Member Author

Choose a reason for hiding this comment

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

these are unchanged, just nested now to share the test gatherer/audit/config with the following test (and assert -> expect)

@@ -408,28 +408,6 @@ class GatherRunner {
log.timeEnd(apStatus);
}

/**
* Generate a set of artfiacts for the given pass as if all the gatherers
Copy link
Collaborator

Choose a reason for hiding this comment

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

aw, no more artfiacts 😢

Copy link
Collaborator
@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

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

I think this all LGTM!

just the one concern about awaiting disposeDriver

} catch (err) {
// cleanup on error
} finally {
// Clean up regardless of error.
GatherRunner.disposeDriver(driver, options);
Copy link
Collaborator

Choose a reason for hiding this comment

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

I like the simplification, but now we can't await it in the success case :/

maybe it doesn't matter and we can add a comment calling out why it doesn't matter?

worth noting that it does clearDataForOrigin which given the recent changes in Chrome has taken multiple seconds on my machine lately :(

Copy link
Member Author

Choose a reason for hiding this comment

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

but now we can't await it in the success case

Good catch, that wasn't intentional. I wonder how bad it would be to await the error case... Presumably it was so errors in disposing didn't overwrite the originating error, which probably often go hand in hand?

Kind of ridiculous we can't express what we mean here.

I could also just change it back, it's not a huge win.

Copy link
Collaborator

Choose a reason for hiding this comment

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

yeah maybe just change it back with a comment so we don't forget this again next time :)

Copy link
Member Author

Choose a reason for hiding this comment

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

This pattern originally popped up way back in #639 (in the course of @wardpeet adding the multiple tabs check!), though originally we didn't wait for disconnect in the failure or success cases.

Looking at #2359, where the successful path was integrated into the promise chain, I'm half convinced we should be doing await GatherRunner.disposeDriver(driver, options).catch(() => {}); in the error case to avoid ever exiting before Chrome is able to exit, but I'm not able to induce a problem, so leaving it as it was :)

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think I'm with you on .catch even if we don't await it, but w/e :)


it('includes a pageLoadError runtimeError over any gatherer runtimeErrors', async () => {
const url = 'https://www.reddit.com/r/nba';
let firstLoad = true;
Copy link
Collaborator

Choose a reason for hiding this comment

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

firstLoad strikes again 😢

Copy link
Member Author

Choose a reason for hiding this comment

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

firstLoad strikes again 😢

yeah, I'm sorry!

@brendankenny
Copy link
Member Author

I think this all LGTM!

need an actual LGTM :)

Copy link
Collaborator
@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

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

LGTM for realz!

} catch (err) {
// cleanup on error
} finally {
// Clean up regardless of error.
GatherRunner.disposeDriver(driver, options);
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think I'm with you on .catch even if we don't await it, but w/e :)

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.

None yet

3 participants