'cancelled' http.client spans due to Xhr responses being falsely reported as requests #4427

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• Provide a link to the affected event from your Sentry account: https://sentry.io/organizations/holistics/performance/holistics-test:1aee0fb08f7d41bba66c77d6413f70ce

Package + Version

• @sentry/browser
• @sentry/node
• raven-js
• raven-node (raven for node)
• other: @sentry/vue, @sentry/tracing

Version:

6.16.1

Description

http.client spans get marked as 'cancelled' due to Xhr responses being falsely reported as requests.

Setup:

• Use vueRouterInstrumentation
• Make some xhr requests before Vue routing happens (i.e. before 'pageload' transaction has even started).

Actual result:

• If the responses (of the before-vue-routing requests) return after Vue routing, they are recognized as new spans.
  Consequently, these spans never receive any further update and eventually get marked as 'cancelled'

Expected result:

• The responses (of the before-vue-routing requests) get discarded?

Troubleshooting:

• For every xhr request, xhrCallBack is called two times:
  1. When the request is created, to start the http.client span
  2. When the request is completed, to finish the http.client span
• However, in the first call, Vue routing has not happened and hence instrumentation has not started the 'pageload' transaction yet. Thus, the execution is halted and the http.client span is not properly initialized. Then, in the second call, handlerData.xhr.__sentry_xhr_span_id__ is not available, so the xhr request completion is mistaken as a new request creation.

Possible fix

• Around https://github.com/getsentry/sentry-javascript/blob/6.16.1/packages/tracing/src/browser/request.ts#L226, do something like if (handlerData.endTimestamp && !handlerData.xhr.__sentry_xhr_span_id__) return;?
  • Implemented in fix(tracing): ignore the xhr/fetch response if its request is not being tracked #4428

Update 1

• fetch also has the similar issue