fix(server-runtime-injection): Resolve the orchestrion ESM hook by path so build tracers follow it - #23687
Conversation
size-limit report 📦
|
|
not sure but this could conflict/overlap with #23685? |
|
@mydea yea, I'll wait until yours lands. |
badd3e7 to
09caa8b
Compare
09caa8b to
e4cd548
Compare
e4cd548 to
8bfd325
Compare
…th so build tracers follow it Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
8bfd325 to
f91a830
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit f91a830. Configure here.
|
Seems fine to me! Maybe a test actually running nft would be nice? |
|
Added `test/nftTrace.test.ts`, which runs |

Stacked on #23679.
What
register.ts(now in@sentry/server-runtime-injection) resolves the orchestrion ESM loader hook from its own on-disk location instead of through the@sentry/server-runtime-injection/hookself-reference, and the standalone e2e app asserts the hook reaches the traced output. It keeps the self-reference as a fallback for a bundled copy, where the relative path points at nothing.Fixes JS-3451.
Why
Module.register()resolves its specifier at runtime.@vercel/nftdoes evaluate those calls, but not through the interop namespace helper rollup emits in the CJS build, which is the build Next.js loads, so the hook never reached traced output.output: 'standalone', Docker and Vercel deploys then lost channel-based instrumentation entirely, and only said so behinddebug: true. The new path is a literal that both builds expose to tracers, computed at runtime so nothing absolute is baked in.