CORS issue on third-parti since v7.13.0 -

[Quentin-Danjou]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which package are you using?

@sentry/gatsby

SDK Version

7.19.0

Framework Version

4.17.2

Link to Sentry event

No response

Steps to Reproduce

Going from anything above 7.12.1 it seems the header

Access-Control-Request-Headers	baggage,sentry-trace

is being added despite having a URL not matching the tracingOrigins. We also tried to use many of the new versions as we know some fixes have been done, but it did not solve (entirely?) the issue.
We tried:
7.17.2 – Did not work
7.17.3 which was the latest when we started to investigate the issue – Did not work
7.19.0 literally 2 hours after its release

• with the new tracePropagationTargets – Did not work
• with shouldCreateSpanForRequest (function doing the RegEx match) - Did not work

Then we bisect to find which version exactly broke (we were initially using a 7.11.x) and found that the first version where the issue is showing is v7.13.0.

We are using a single package.json with:
@sentry/gatsby
@sentry/node (used by our lambdas)
@sentry/tracing

We use Sentry in a sentry.config.js with the following full content:

import * as Sentry from "@sentry/gatsby";
import { Integrations } from "@sentry/tracing";

Sentry.init({
  dsn: "--The DSN url string--",
  sampleRate: 0.4,
  tracesSampleRate: 0.1,
  release: process.env.GATSBY_COMMIT_REF,
  environment: process.env.GATSBY_SENTRY_ENV,
  integrations: [
    new Integrations.BrowserTracing({
      tracingOrigins: [
        /^http:\/\/localhost/,
        /^https:\/\/www.ourdomain.com/,
        /^https:\/\/ourdomain.com/,
        /^https:\/\/checkout.ourdomain.com/,
        /^https:\/\/store.ourdomain.com/,
      ],
    }),
  ],
});

Expected Result

Header should not be attached.

Actual Result

Here is the request having a CORS issue:

[AbhiPrasad]

I wonder if this is related to #5697, which was introduced with 7.13.0. https://github.com/getsentry/sentry-javascript/blob/master/CHANGELOG.md#7130

@timfish could you dig deeper here when you get some time?

[Lms24]

If we can confirm that this is related to the keepAlive flag, we should probably think about reverting this change.
Possibly Related: #6049

[Quentin-Danjou]

First, thank you for your help, we unsuccessfully tried to have a quick look ourselves at the changes made in 7.13.0 to understand the origin of the issue.

This is what we tried:
=> Updating to v7.18.0 as in #6049
sentry.config.js

import * as Sentry from "@sentry/gatsby";
import { Integrations } from "@sentry/tracing";

Sentry.init({
  dsn: "DSN string",
  sampleRate: 0.4,
  tracesSampleRate: 0.1,
  release: process.env.GATSBY_COMMIT_REF,
  environment: process.env.GATSBY_SENTRY_ENV,
  transportOptions: { fetchOptions: { keepalive: false } },
  integrations: [
    new Integrations.BrowserTracing({
      tracingOrigins: [
        /^http:\/\/localhost/,
        /^https:\/\/www.ourdomain.com/,
        /^https:\/\/ourdomain.com/,
        /^https:\/\/checkout.ourdomain.com/,
        /^https:\/\/store.ourdomain.com/,
      ],
    }),
  ],
});

The issue is still there:

I am testing with Firefox and Chrome (It is worth noting that Firefox does not have keepalive).

Edit: it also seems to be specific to some third party. We are experiencing it only with exponea.com but others work fine

[timfish]

Can you confirm that you can disable span creation and header attachment completely?
With the latest version (7.19.0) you can do that by returning false from the shouldCreateSpanForRequest function. When there are no spans, we shouldn't be attaching headers either.

Also ensure that @sentry/tracing is the same version as other Sentry dependencies.

new Integrations.BrowserTracing({
  shouldCreateSpanForRequest: _ => false
})

At this point you should no longer get the OPTIONS request because no headers should be attached.

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀