@opentelemetry/context-zone Maximum call stack size exceeded occurs when the Redux Tool Chrome Extension is enabled for Next v13.5.4

[WeirShi]

trafficstars

What happened?

OpenTelemetry Setup Code

import { WebTracerProvider } from '@opentelemetry/sdk-trace-web'
import { Resource } from '@opentelemetry/resources'
import { SemanticResourceAttributes } from '@opentelemetry/semantic-conventions'
import { ZoneContextManager } from '@opentelemetry/context-zone'
import { registerInstrumentations } from '@opentelemetry/instrumentation


const provider = new WebTracerProvider()
provider.register({
  contextManager: new ZoneContextManager(),
})

package.json

"dependencies": {
    "@opentelemetry/api": "^1.4.0",
    "@opentelemetry/context-zone": "^1.9.1",
    "@opentelemetry/core": "^1.13.0",
    "@opentelemetry/exporter-trace-otlp-http": "^0.35.1",
    "@opentelemetry/instrumentation": "^0.39.1",
    "@opentelemetry/instrumentation-fetch": "^0.39.1",
    "@opentelemetry/instrumentation-xml-http-request": "^0.39.1",
    "@opentelemetry/otlp-transformer": "^0.39.1",
    "@opentelemetry/resources": "^1.13.0",
    "@opentelemetry/sdk-trace-web": "^1.13.0",
    "@opentelemetry/semantic-conventions": "^1.13.0"
  }

Relevant log output

No response

[dyladan]

The provided screenshot is too low resolution to read and appears to be minified code. Can you please copy and paste a text version of the stacktrace?

Can you also try using the stack context manager and see if the bug still persists? This context manager is not recommended for production but should help us to eliminate variables for debugging.

[WeirShi]

This is the stack error message

RangeError: Maximum call stack size exceeded at normalizeRouterState (7864-c71cb59fef1aa50d.js:1:73933) at normalizeRouterState (7864-c71cb59fef1aa50d.js:1:74483) at normalizeRouterState (7864-c71cb59fef1aa50d.js:1:74483) at normalizeRouterState (7864-c71cb59fef1aa50d.js:1:74483) at normalizeRouterState (7864-c71cb59fef1aa50d.js:1:74483) at normalizeRouterState (7864-c71cb59fef1aa50d.js:1:74483) at normalizeRouterState (7864-c71cb59fef1aa50d.js:1:74483) at normalizeRouterState (7864-c71cb59fef1aa50d.js:1:74483) at normalizeRouterState (7864-c71cb59fef1aa50d.js:1:74483) at normalizeRouterState (7864-c71cb59fef1aa50d.js:1:74483)

and May I ask if there is any other package to replace @opentelemetry/context-zone?
Thanks

[dyladan]

normalizeRouterState is not opentelemetry code. This might be caused by the extension. Can you please provide a reproduction so we can look into this further?

[dyladan]

What is making you think this is caused by the context manager? I don't see reference to it in the stacktrace or error message?

[WeirShi]

Demo

This is a Next.js demo project that includes a secondary development of sdk.js based on OpenTelemetry and imports the "context" package. In Next.js, if you load this project using the "Script beforeInteractive" or "Script afterInteractive" modes during production builds and with Redux DevTools enabled, it will result in an error stating "Maximum call stack size exceeded.". However, if you load the project using the "lazyOnload" mode, this issue should not occur.

[MSNev]

with Redux DevTools enabled, it will result in an error stating "Maximum call stack size exceeded.". However, if you load the project using the "lazyOnload" mode, this issue should not occur.

This REALLY does sound like the DevTools is adding something to the base prototype (of some class) that has a recursive loop (back to a parent object) so that when the recursive code attempt to traverse the object tree it goes forever.

And based on the normalizeRouterState in the recursive call stack this seems to be what that function is doing.

So it seems like the DevTools is seeing something that the Context Manager is adding that triggeres this scenario -- exactly what! Well thats the million dollar question. Can you (@WeirShir) do some debugging and identify what that normalizeRouterState is repeating on as this will help identify "who" is the culprit. I suspect a fix will be required in the normalizeRouterState and/or the DevTools and not (specifically) in the Context Manager.

[WeirShi]

This sounds like an issue I need to raise with Redux Tool officials.

[markerikson]

FWIW normalizeRouterState is part of Next's use of the Redux DevTools:

• https://github.com/vercel/next.js/blob/ffdfd33251165d8b2f092568c8e4e5f08c71a636/packages/next/src/client/components/use-reducer-with-devtools.ts#L12

As far as I know, the Redux DevTools don't do anything to "mess with prototypes".

[icyJoseph]

Really interesting... in this stackblitz, https://stackblitz.com/edit/github-wywdtb?file=src%2Fapp%2Flayout.tsx

You can npm i, and then npm run build && npx serve out - and you'll see in the console the issues.

What seems to happen is that the object prototype is polluted, or somehow there's a self-referential object that just stacks up calls to the normalizeRouterState function.

I am more on the first option:

Why would the zone object end up in the Next.js redux dev tools code 🤔 it has to be pollution right? Note that this reproduction repository uses Next.js' export mode as well.

[icyJoseph]

Once you get to this point of the debugging, past the __PAGE__ stuff from RSC, there's no way back, it'll just stack up calls to normalizeRouterState 🤔

[dyladan]

This sounds like an issue I need to raise with Redux Tool officials

@WeirShi did you ever raise this with redux tools?

[markerikson]

@dyladan per above this appears to be an issue with Next's code, not the Redux DevTools

[dyladan]

Sorry. I guess the more pertinent question is "can this be closed?" It doesn't seem to be caused by anything we're doing

[JamieDanielson]

There hasn't been much interaction on this and it does so far seem to be something in either Next or Redux DevTools. Will close this out for now, but if something new comes up leaning toward otel-js needing a fix, feel free to comment or open a new issue.