core: handle invalid network timing data #6780
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
patrickhulce
requested review from
brendankenny and
paulirish
as code owners
brendankenny
approved these changes
Dec 12, 2018
| @@ -272,6 +272,9 @@ module.exports = class NetworkRequest { | |||
| * @param {LH.Crdp.Network.ResourceTiming} timing | |||
| */ | |||
| _recomputeTimesWithResourceTiming(timing) { | |||
| // Don't recompute times if the data is invalid. RequestTime should always be a thread timestamp. | |||
| // If we don't have receiveHeadersEnd, we really don't have more accurate data. | |||
| if (timing.requestTime === 0 || timing.receiveHeadersEnd === -1) return; | |||
There was a problem hiding this comment.
ha, I believe this would have saved me a lot of time figuring out how to generate the right network request events in #6171
| @@ -269,8 +269,11 @@ class PageDependencyGraph { | |||
| const networkNodeOutput = PageDependencyGraph.getNetworkNodeOutput(networkRecords); | |||
| const cpuNodes = PageDependencyGraph.getCPUNodes(traceOfTab); | |||
|
|
|||
| const rootRequest = networkRecords.reduce((min, r) => (min.startTime < r.startTime ? min : r)); | |||
| // The root request is the earliest network request, using position in networkRecords array to break ties. | |||
| @@ -269,8 +269,11 @@ class PageDependencyGraph { | |||
| const networkNodeOutput = PageDependencyGraph.getNetworkNodeOutput(networkRecords); | |||
| const cpuNodes = PageDependencyGraph.getCPUNodes(traceOfTab); | |||
|
|
|||
| const rootRequest = networkRecords.reduce((min, r) => (min.startTime < r.startTime ? min : r)); | |||
| // The root request is the earliest network request, using position in networkRecords array to break ties. | |||
| const rootRequest = networkRecords.reduce((min, r) => (r.startTime < min.startTime ? r : min)); | |||
There was a problem hiding this comment.
might be overkill, but should we pull this out into another method on NetworkAnalyzer like findMainDocument? I can see it usable by others (if they remember it's there).
There was a problem hiding this comment.
I'd want to shift consumers to be using the graph as the source of truth, so hopefully no one else needs to compute this too? :)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
In LR, the
timingobject can be defined but have no valid data (requestTime: 0, receiveHeadersEnd: -1). This was unexpected and was causing problems later on down the chain for lantern.Masking the problem was the fact that the
rootNodeof the lantern graph was trying to pick the earliest network request but was breaking ties by choosing the last network record in the array. When the requestTimes were0, it just ended up picking the last one and losing the real root node. This PR also adds some sanity checks around that to make sure we'd fail earlier about those unexpected cases.Related Issues/PRs
fixes #6378