Failed to execute 'setRequestHeader' on 'XMLHttpRequest': The object's state must be OPENED.

[TimTheToad]

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 SDK are you using?

Sentry Browser CDN bundle

SDK Version

7.85.0

Framework Version

No response

Link to Sentry event

No response

SDK Setup

    Sentry.onLoad(function () {
        Sentry.init({
            environment: "staging",
            release: "v1.0",
            beforeSend(event) {
                if ('NO' !== 'YES') {
                    return null
                }
                return event
            },
            beforeBreadcrumb(breadcrumb, hint) {
                if (breadcrumb.category === 'xhr') {
                    // hint.xhr is a whole XHR object that you can use to modify breadcrumb
                    breadcrumb.data = hint.xhr
                }
                return breadcrumb
            },
            integrations: [
                new Sentry.Replay({
                    networkDetailAllowUrls: ['*'],
                }),
            ],

        })
    })

---

We are using CDN Bundle:
bundle.replay.min.js

Steps to Reproduce

Any error invoked and captured by Sentry will generate the foillowing error:
InvalidStateError: Failed to execute 'setRequestHeader' on 'XMLHttpRequest': The object's state must be OPENED.

This suddenly started to appear on the 27th of November.
Our only way to resolve it was to remove Sentry in our code.

Expected Result

Expected result would be a captured Sentry event that we later may review.

Actual Result

Stack Trace:

As you can see it seems to me like Sentry is intercepting axios requests. (Marked the row that throws the error. )

We have tried updating axios to the latest version as well without any results.

[lforst]

Hi, I saw that you already wrote in on Discord. Thanks for raising this issue. Would you mind sharing a way to consistently reproduce this bug? Ideally by sharing a small repo or stackblitz. Thank you!

[TimTheToad]

We have been going back and forth with support via email as well. From that conversation we managed to get access to older bundles, primarily bundles before the 27th.

Our current setup looks like this now:

`<script src="https://browser.sentry-cdn.com/7.81.0/bundle.replay.min.js" integrity="sha384-7dVJzCgPJKHCfCuRyoGhuMDozd1FWu/GdTDiaAxJK4hrOhKoQTtG+yV4DsbRDLAl" crossorigin="anonymous" ></script>

<script>
    Sentry.init({
        dsn: "https://xxx9@o45xxxxx.ingest.sentry.io/45xx",
        environment: "{{ SENTRY_ENVIRONMENT }}",
        release: "v1.0",
        beforeSend(event) {
            if ('{{ SENTRY_SEND_ERRORS }}' !== 'YES') {
                return null
            }
            return event
        },
        beforeBreadcrumb(breadcrumb, hint) {
            if (breadcrumb.category === 'xhr') {
                // hint.xhr is a whole XHR object that you can use to modify breadcrumb
                breadcrumb.data = hint.xhr
            }
            return breadcrumb
        },
        integrations: [
            new Sentry.Replay({
                networkDetailAllowUrls: ['{{ ALLOWED_HOSTS|safeseq|join:"', '"}}'],
            })
        ],
    })
</script>`

And everything works as expected.

We have removed the CDN loader and are now explicit in what version we use.

So we can easily reproduce the error by switching out

<script src="https://browser.sentry-cdn.com/7.81.0/bundle.replay.min.js" integrity="sha384-7dVJzCgPJKHCfCuRyoGhuMDozd1FWu/GdTDiaAxJK4hrOhKoQTtG+yV4DsbRDLAl" crossorigin="anonymous" ></script>

to this:

<script src="https://browser.sentry-cdn.com/7.85.0/bundle.replay.min.js" integrity="sha384-COVyLVcWnhEGHFdIcbgDG7Ccu5Dpj9p9pILO9Vw3iIlKLj7Z9aVxQTPsit1baJiY" crossorigin="anonymous"></script>

And we consistantly raise the error mentioned in the original post.

[lforst]

@mydea Did we change something in Replay that could cause this?

Edit: It's probably this PR #9623

[mydea]

Hmm, I don't think it's the PR you linked (that came later and didn't really touch this), more likely #9542 (or possibly, but less likely, #9622) - I'll take a look!

[mydea]

I identified the problem and opened a PR to fix it: #9770