Open
Description
Link to the code that reproduces this issue
https://github.com/shkreios/next-js-instrumentation-bug-reproduction
To Reproduce
- Open the codesandbox
- Start the next dev server
- Open the app on http://localhost:3000
- Click the request button
- Inspect the logs see that the mutating of the store object inside instrumentation.ts has no effect to the imported store object inside api/update-store
Current vs. Expected behavior
I would expect the code inside instrumentation.ts
to be able to mutate the store object.
Console output
// log from inside instrumentation.ts successfully setting the onUpdate prop on the store object
Store listener is ready { update: [Function: update], onUpdate: [Function (anonymous)] }
log from inside the api/update-store/route.ts showing a different object which does not have the change
{ update: [Function: update] }
Provide environment information
Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6000
Available memory (MB): 32768
Available CPU cores: 8
Binaries:
Node: 20.17.0
npm: 10.8.2
Yarn: 1.22.19
pnpm: 9.9.0
Relevant Packages:
next: 15.0.0-canary.137 // Latest available version is detected (15.0.0-canary.137).
eslint-config-next: N/A
react: 19.0.0-rc-7771d3a7-20240827
react-dom: 19.0.0-rc-7771d3a7-20240827
typescript: 5.3.3
Next.js Config:
output: N/A
Which area(s) are affected? (Select all that apply)
Instrumentation, Runtime
Which stage(s) are affected? (Select all that apply)
next dev (local), next start (local), Vercel (Deployed), Other (Deployed)
Additional context
My main use case for this approach, as demonstrated in the example, is to attach listeners to the data layer once. A more complex scenario would involve attempting to share an EventEmitter
object. However, it would be less obvious that the objects within instrumentation.ts and the API route are not identical.