Issue Cannot create property 'normalizeDepth' on string '**non-serializable**' #4719
Comments
|
Facing same issue, looks like since #4574 |
|
Ah, yes - the hack to debug one bug (the one you mentioned, @AntoineMontane) causing another bug. Sorry about that. I will fix this but want to let #4689 go through first, since it touches the same code. |
lobsterkatie
added
Package: core
…oring (#4761) Currently, if an error occurs anywhere in the normalization process, the entire value is clobbered, in favor of the string `"**non-serializable**"`. This has a few drawbacks: - All data is lost, even data that wasn't malformed - It's harder to tell where the problem is, because there's no way to know which part of the data caused the problem - It's possible to pass `normalize` an object and get back a string, which can prove problematic if data is later added to the normalized property as if it were still an object (see the issue linked below). The goal of this change, then, was to identify all of the places where errors could occur and catch them right there, rather than relying on the `try-catch` in the main `normalize` function. In order to make this easier to reason about, the normalization code was first streamlined a bit. Key changes: - `serializeValue` and `makeSerializable` have been combined into a single function, `stringifyValue`, and any code not resulting in a string has been moved into the calling function. - All code in `stringifyValue` has been wrapped in a `try-catch`, so that errors which originate there will only affect the value at hand, rather than then entire object. - When `"**non-serializable**"` has to be used, it's now accompanied by the message belonging to the error which broke the serialization. - When the outer `normalize` function needs to return `"**non-serializable**"`, it now wraps it in an object, so that other data can still be added. - The `walk` function has been renamed `visit`, to better conform to the language of the Visitor Pattern. For the moment, it's still aliased to `walk` when exported, to preserve backwards compatibility. - The `getWalkSource` function has been renamed `convertToPlainObject`, to better reflect what it does, and some of its repetitive code has been extracted into the `serializeEventTarget` and `getOwnProperties` functions. Fixes #4719
|
Having the same error pop up in my Sentry, what can I do? |
|
@lobsterkatie in which release is this fixed? still facing this in 6.19.7 UPD: So why is this issue closed? |
|
I'm getting the same error using @nuxt/sentry 5.1.7 which uses sentry 6.19.7 |
|
Though I'll admit I don't quite understand how my earlier PR didn't fix it, it's now a moot point, as I just merged #5267, which removes the offending code entirely. It should be released next week as part of 7.2. Sorry for the delay here! |
Is there an existing issue for this?
How do you use Sentry?
Sentry Saas (sentry.io)
Which package are you using?
@sentry/browser
SDK Version
6.18.2
Framework Version
No response
Link to Sentry event
https://sentry.io/organizations/upfeelcom/issues/3043424684/events/c800fc30c50c4f33a7487f499b279dbf/?project=5960454
Steps to Reproduce
Using nuxt integration @nuxtjs/sentry
config :
sentry: {
sourceMapStyle: "hidden-source-map",
publishRelease: process.env.SENTRY_RELEASE ? {
release: process.env.SENTRY_RELEASE,
stripPrefix: ["/** redacted /"],
urlPrefix: process.env.PUBLIC_PATH,
setCommits: {
repo: "/ redacted **//website",
commit: process.env.GIT_COMMIT,
ignoreMissing: true,
},
deploy: {
env: process.env.SENTRY_ENVIRONMENT as string,
url: baseUrl,
},
} : false,
config: {
environment: process.env.SENTRY_ENVIRONMENT,
release: process.env.SENTRY_RELEASE,
//normalizeDepth:3,
},
tracing: true,
},
Expected Result
An actual trace
Actual Result
TypeError: Cannot create property 'normalizeDepth' on string 'non-serializable'
at eventToSentryRequest(./node_modules/@sentry/core/esm/request.js:70:21)
at sendEvent(./node_modules/@sentry/browser/esm/transports/base.js:35:34)
at sendEvent(./node_modules/@sentry/core/esm/basebackend.js:33:30)
at call(./node_modules/@sentry/core/esm/baseclient.js:397:28)
at _sendEvent(./node_modules/@sentry/browser/esm/client.js:70:37)
at onfulfilled(./node_modules/@sentry/core/esm/baseclient.js:469:19)
at Array.(./node_modules/@sentry/utils/esm/syncpromise.js:100:37)
at ? (./node_modules/@sentry/utils/esm/syncpromise.js:71:29)
at Array.forEach()
at _executeHandlers(./node_modules/@sentry/utils/esm/syncpromise.js:65:28)
at executor(./node_modules/@sentry/utils/esm/syncpromise.js:121:19)
at new e(./node_modules/@sentry/utils/esm/syncpromise.js:80:13)
at then(./node_modules/@sentry/utils/esm/syncpromise.js:89:16)
at _processEvent(./node_modules/@sentry/core/esm/baseclient.js:460:14)
at _captureEvent(./node_modules/@sentry/core/esm/baseclient.js:406:21)
at onfulfilled(./node_modules/@sentry/core/esm/baseclient.js:87:51)
at Array.(./node_modules/@sentry/utils/esm/syncpromise.js:100:37)
at ? (./node_modules/@sentry/utils/esm/syncpromise.js:71:29)
at Array.forEach()
at _executeHandlers(./node_modules/@sentry/utils/esm/syncpromise.js:65:28)
at executor(./node_modules/@sentry/utils/esm/syncpromise.js:121:19)
at new e(./node_modules/@sentry/utils/esm/syncpromise.js:80:13)
at then(./node_modules/@sentry/utils/esm/syncpromise.js:89:16)
at apply(./node_modules/@sentry/core/esm/baseclient.js:87:14)
at _invokeClient(./node_modules/@sentry/hub/esm/hub.js:382:35)
at captureMessage(./node_modules/@sentry/hub/esm/hub.js:158:14)
at callback(./node_modules/@sentry/integrations/esm/reportingobserver.js:66:21)
at withScope(./node_modules/@sentry/hub/esm/hub.js:84:13)
at _loop_1(./node_modules/@sentry/integrations/esm/reportingobserver.js:44:17)
at e.handler(./node_modules/@sentry/integrations/esm/reportingobserver.js:72:17)
The text was updated successfully, but these errors were encountered: