-
Notifications
You must be signed in to change notification settings - Fork 570
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
update timingInfo to follow new spec changes #1143
Conversation
finalServiceWorkerStartTime: 0, | ||
finalNetworkResponseStartTime: 0, | ||
finalNetworkRequestStartTime: 0, | ||
endTime: 0, | ||
encodedBodySize: 0, | ||
decodedBodySize: 0, | ||
finalConnectionTimingInfo: null, | ||
...init |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed this because the spec states to "return a new fetch timing info whose start time and post-redirect start time are timingInfo’s start time.". Since only startTime and postRedirectStartTime can be changed it seems more explicit to show that their values are the only ones being updated.
const timingInfo = makeTimingInfo({ | ||
startTime: currenTime, | ||
postRedirectStartTime: currenTime | ||
const timingInfo = createOpaqueTimingInfo({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this falls under the category of an opaque timing info but it follows the guidelines of having default values and having startTime = postRedirectStartTime
Codecov Report
@@ Coverage Diff @@
## main #1143 +/- ##
=======================================
Coverage 93.88% 93.88%
=======================================
Files 40 40
Lines 3809 3809
=======================================
Hits 3576 3576
Misses 233 233
Continue to review full report at Codecov.
|
Can you please add a unit test? |
I don't know how the following code would be triggered in this package, or at all? I looked for wpt tests and found this open issue that relies upon this spec change to trigger. So we need that 2nd spec change (which adds timingInfo to network errors, and even then, would undici ever trigger this condition?). I know that's a lot of word soup but I'm trying to say that this PR is needed for a future PR that updates how network errors are handled. I can trigger a network error being made ( |
@ronag wdyt? |
I'm ok with merging. It's literally following the spec and for now it's not observable. I was hoping to eventually make timing info observable through e.g. diagnostics channels. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Implements spec changes from whatwg/fetch@8659a25
refs: #1141 (this didn't take me very long because it was mostly just renaming the utility function)