Sentry-javascript: Breadcrumbs stringify object

[mitsuhiko]

It might make sense to improve the rendering of objects passed as breadcrumbs. Currently they become [object Object] which is not very helpful.

[Sija]

Rendering objects as expandable tree structures would be nice too!

[benvinegar]

Rendering objects as expandable tree structures would be nice too!

Breadcrumbs are intentionally designed to be lightweight "hints" ... we want to avoid just straight-up rendering big trees of embedded data. There is a payload data limit.

[lincolndbryant]

Sounds super risky. We've found other 3rd party scripts wrapping console.log and trying to stringify DOM elements or other large/cyclical structures; leading to performance degradation or errors. You are free to record more complex info in your own app then append it to the reported messages via the dataCallback feature.

[fungilation]

Disagree. Chrome is doing it in improved console.log since 60/61, it can be "safe".

[ghost]

+1

[kamilogorek]

We can utilize my node serializer here maybe. We'll see.

[arabold]

Wait, what?! I'm confused as Sentry is logging my console logs automatically. But then it logs everything as useless [object Object] and the official statement is that this is intended because that's not what breadcrumbs were designed for? o_O

But for everybody else who ends up in this thread wondering how to fix this, there's a simple solution: Set the breadcrumbCallback as described in the JavaScript Configuration. This should allow you to stringify your log the way you want.

[kamilogorek]

the official statement is that this is intended because that's not what breadcrumbs were designed for? o_O

There's nothing stopping you from doing a correct console.log(JSON.stringify(data, null, 2)) to solve this issue.

However, right now we have a breadcrumb hints that allows users to change this behavior with ease: https://github.com/getsentry/sentry-javascript/issues/1401#issuecomment-418631326

[krzcho]

I got various function calls wrapped with Sentry.wrap() and all I got in the event is:

console | XYZfunction,[object Object],[object Object]
logger | console
arguments | [["XYZfunction","[Object]","[Object]"]]

breadcrumb. Could someone please provide an example of how to extend useless [object Object] info?

[kamilogorek]

@krzcho

Sentry.init({
  dsn: '__PUBLIC_DSN__',
  normalizeDepth: 5 // or whatever depths suits your needs
})

[krzcho]

Thx @kamilogorek, what is the default? Zero?
This parameter is not described here: https://docs.sentry.io/error-reporting/configuration/?platform=javascript

[kamilogorek]

It's 3 by default. It's described here https://docs.sentry.io/platforms/javascript/react/#normalization-depth but because It's a global option, we already changed it in our docs to be in the place you linked - https://github.com/getsentry/sentry-docs/pull/1921/files#diff-38f6cf305f4368a383a64151307349fdR54-R56 (already merged, to be deployed)

[Niaro]

@kamilogorek Hi there! Would be awesome to have object representation of a sort in the breadcrumbs on the UI. A blob of text is not really perceivable...

Also, LogRocket doesn't impose any restriction on the payload size for example, which is sweet, I could log all my redux actions we ease) Not complaining, but they somehow managed the payload size problem, some binary voodoo we diffs

[kamilogorek]

Would be awesome to have object representation of a sort in the breadcrumbs on the UI. A blob of text is not really perceivable...

There's a breadcrumb.data field that can contain any object which will be displayed in the UI.

Sentry.addBreadcrumb({
  category: "xhr",
  data: {
    key1: {
      data: "fields",
      answer: 42,
    },
    key2: {
      ok: "yes",
      question: 2020,
    },
    key3: {
      other: "field",
      answer: 1337,
    },
  },
});

Also, LogRocket doesn't impose any restriction on the payload size for example, which is sweet, I could log all my redux actions we ease) Not complaining, but they somehow managed the payload size problem, some binary voodoo we diffs

Agree, however it requires way more work than just the SDK changes. Hopefully one day :)