-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
fix: Make sure fetch requests are being timed correctly #2772
Conversation
9d54db5
to
d0a4be8
Compare
size-limit report
|
Good refactor 👍 |
@@ -40,9 +40,9 @@ export interface RequestInstrumentationOptions { | |||
} | |||
|
|||
/** Data returned from fetch callback */ | |||
interface FetchData { | |||
export interface FetchData { |
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.
Why do we need to export FetchData
and fetchCallback
?
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.
For tests
@@ -63,7 +63,7 @@ export class IdleTransaction extends Transaction { | |||
private _prevHeartbeatString: string | undefined; | |||
|
|||
// Amount of times heartbeat has counted. Will cause transaction to finish after 3 beats. | |||
private _heartbeatCounter: number = 1; | |||
private _heartbeatCounter: number = 0; |
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.
Was this wrong before?
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.
Off by 1
Motivation
Earlier today, Daniel raised up some concerns about incorrect timings for fetch spans. This PR splits up each of those concerns into actionable items, and aims to address them.
Implementation
First it takes a look at an issue where
fetch
spans were being doubled in@sentry/tracing
. This happens because we did not store the span correctly, so there was no span to finish. I have fixed this and added tests.handlerData.fetchData.__span = span.spanId
was added for the fix.Second, we took a look at an issue affecting both
@sentry/apm
and@sentry/tracing
where the end timing for spans with the same description ended up being the same. This was because we have logic inperformance
to adjustfetch
andxhr
span timestamps based on description.Because we could not figure out a good way to keep this while recognizing unique URLs, we decided to delete this code as our tracking of spans should be enough to ensure accurate timestamps.