Sentry browser helper swallowing exception and not sending event

[lpaulger]

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/react

SDK Version

7.13.0

Framework Version

react 17.0.2

Link to Sentry event

No response

Steps to Reproduce

I have a react component where I observe a valid error because we access a prop of an undefined object. My concern is I am not seeing the error appear in Sentry, and while investigating, it seems that https://github.com/getsentry/sentry-javascript/blob/master/packages/browser/src/helpers.ts#L117 exception is thrown and never sent to sentry and I can't understand why.

example react code where the error happens

state of my component which causes the error:

Categories = {};

myObject = {rule: {Category: 'MyCategory'}};

<strong 
  {Categories[myObject.rule.Category].title}
</strong>

When the error is thrown, it is being caught from within browser/src/helpers

TypeError: Cannot read properties of undefined (reading 'title')

Expected Result

line 117 of the helper throws the exception, I expect that it would be sent to sentry but it never appears.

I have set up a beforeSend within Sentry.init to verify all sent requests, and this case it is never called.

Sentry.init({
  dsn: "...",
  environment: "...",
  release: "...",
  beforeSend: (event, hint) => {
    console.log({ event, hint });

    // for debugging I want to see what goes to sentry
    return null;
  },
 
});

### Actual Result

thrown exception from react is never sent to Sentry. 

I'm not sure how to create a reproduction without a public sentry instance.

[lforst]

Thanks for writing in. This looks weird.

When in the lifecycle of your application are you calling Sentry.init()? It should be before rendering your app.
Additionally, can you try setting debug: true in the init options and see if there is anything useful in the logs?

[lforst]

Also if you're able to provide a small reproduction app we can debug this more effectively! (You can leave the DSN out and we can insert our own)

[lpaulger]

Thanks for writing in. This looks weird.

When in the lifecycle of your application are you calling Sentry.init()? It should be before rendering your app. Additionally, can you try setting debug: true in the init options and see if there is anything useful in the logs?

We're currently working with Gatsby to return our initial render and it looks like this:

gatsby-browser.js

...
require('./config/sentry');
...
exports.wrapRootElement = ({ element }) => {
  const store = getStore();

  return (
    <HelmetProvider>
      <Provider store={store}>
        <BrowserRouter>{element}</BrowserRouter>
      </Provider>
    </HelmetProvider>
  );
};

config/sentry.ts

import * as Sentry from '@sentry/react';
import { BrowserTracing } from '@sentry/tracing';

Sentry.init({
  dsn: <placeholder>,
  environment: window.location.hostname,
  integrations: [new BrowserTracing()],
  release: process.env.GATSBY_COMMIT_SHA,
  ignoreErrors: [
    'ResizeObserver loop limit exceeded',
    'ResizeObserver loop completed with undelivered notifications.',
  ],
  denyUrls: [
    // Chrome extensions
    /extensions\//i,
    /^chrome:\/\//i,
  ],
});

I'll throw in the debug flag and see if I can get more information, and if I find time I'll try and create a reproduction app 👍

[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 🥀

[lpaulger]

Sorry for the delay in responding. I had time to dig into this with the debug flag set to true and I was seeing that the allowUrl regex was responsible for blocking the error from being logged

Digging into this, I was trying to understand why the error locally would be considered outside of the regex. Since I was including localhost in the allowUrls. Then I realized the files were being loaded from webpack-internal:///./node_modules... and when adding that I was able to see the event logged.

So I think this is a non-issue. Thank you for the advice to investigate 🙇