fix(node): Distinguish isolated transform failures from bundling in the runtime warning - #24242
Open
mydea wants to merge 3 commits into
Open
fix(node): Distinguish isolated transform failures from bundling in the runtime warning#24242mydea wants to merge 3 commits into
mydea wants to merge 3 commits into
Conversation
Contributor
size-limit report 📦
|
…he runtime warning The runtime loader emitted the always-on "`@sentry/server-runtime-injection` was bundled ... loads uninstrumented" warning for ANY `TypeError` thrown while transforming a module, misattributing unrelated failures to bundling and pointing users at externalizing the package (which can break other setups). - Include the underlying error in the warning, so it is self-diagnosing rather than asserting a cause the reader cannot verify. - Only claim "bundled" for the transform pipeline itself going missing (`parse`/`generate is not a function` — the fingerprint of a bundler tree-shaking the vendored parser, which fails every module the same way), guarded by nothing having been instrumented yet. Any other transform `TypeError` (e.g. `transform is not a function`) gets a scoped "Could not instrument <module>" message that points at reporting it, not changing the build. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mydea
force-pushed
the
fn/improve-orchestrion-transform-warning
branch
from
September 9, 2026 12:14
a6b76a9 to
64ba1e8
Compare
mydea
commented
Sep 9, 2026
|
|
||
| // Only the parser/generator primitives going missing means the transformer was stripped; a | ||
| // non-empty `runtime` list (something was already instrumented) proves it was not. | ||
| const pipelineStripped = /\b(?:parse|generate)\d* is not a function\b/.test(reason); |
Member
Author
There was a problem hiding this comment.
note that this is def. not perfect, and if this is minified/renamed to something else, this will not trigger. in that case it falls back to the generic handling, which is OK I'd say.
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
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 64ba1e8. Configure here.
…r renaming The stripped-transformer fingerprint matched `parse`/`generate` with an optional digit suffix, which only covers esbuild's numeric deconfliction (`parse2`). Rollup/Vite deconflict with a `$N` suffix (`parse$1`) and production minifiers rename to short opaque names (`e`), so a genuinely bundled pipeline fell through to the isolated branch and told users "this is not a bundling problem". Match the shape of the error (a bare `<ident> is not a function`) plus the fact that nothing was ever instrumented, rather than the primitive name. Keep `transform is not a function` as the explicit isolated carve-out (a local dispatch read under its real name from an unbundled install) and anchor the regex so member-expression failures (`x.y is not a function`) stay isolated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mydea
marked this pull request as ready for review
September 9, 2026 14:14
mydea
requested review from
stephanie-anderson
and removed request for
a team
September 9, 2026 14:14
timfish
approved these changes
Sep 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The runtime loader emitted the always-on
[Sentry] @sentry/server-runtime-injection was bundled ... loads uninstrumentedwarning for anyTypeErrorthrown while transforming a module. That equated "a transform threw a TypeError" with "the transformer was stripped by a bundler", so an unrelated per-module failure was reported as a bundling problem — pointing users at externalizing the package, which can itself break other setups.This makes the warning honest and self-diagnosing:
debug: truestill logs the full error/stack).parse/generate is not a function, the fingerprint of a bundler tree-shaking the vendored meriyah/astring parser, which fails every module the same way — guarded by nothing having been instrumented yet (a transformer that already instrumented something is provably not stripped). Any other transformTypeError(e.g.transform is not a function) now gets a scopedCould not instrument <module> (...)message that points at reporting it, not changing the build.Root cause of the misclassification: the callback branched on
error instanceof TypeErroralone. The systemic (stripped-transformer) case has a distinct signature (parse/generate is not a function), so classifying on that — with the success marker as a secondary guard — separates it from isolated per-module failures with a reasonable success rate.A message-based heuristic is the pragmatic fix here; a follow-up upstream change to the transformer (
nodejs/orchestrion-js) to throw typed/coded errors would let this classification be exact rather than string-matched.Related to #24240, which removes the specific registration-only cause that surfaced this; this hardens the warning for any remaining/future cause.
🤖 Generated with Claude Code