fix(core,browser): Handle errors from other realms - #22926
Conversation
There was a problem hiding this comment.
@davidmurdoch thanks for opening this PR! The fix sounds reasonable to me! One request: could you add a browser integration test that demonstrates the real-life use case? I believe this should happen with an iframe throwing an error with a cause but if you had a different use case that triggered this PR please feel free to use this as a blueprint for the test.
The failing size-limit check is not an issue from your PR. If you rebase it to latest develop it should be gone.
67da060 to
509b845
Compare
Done. Let me know if you need anything else. The use case for me specifically is running Sentry within lavamoat, which makes use of SES Compartments - the |
Replace realm-sensitive Error constructor checks with the existing isError helper. Preserve the fetch TypeError restriction by checking the error name, and add cross-realm regression coverage. Co-Authored-By: OpenAI Codex <codex@openai.com>
509b845 to
692150a
Compare
|
I rebased this to latest develop and resolved the conflict introduced by #22869. Gonna merge once CI passes |
Some event-processing paths failed to recognize errors created in another JavaScript realm. This preserves linked causes and AggregateError children, recognizes error-valued object properties, and applies fetch TypeError hostname enhancement across realm boundaries.
Root cause
instanceof Error,instanceof TypeError, and equivalent constructor-based checks depend on prototype identity. Errors from iframes, workers, or other realms have different intrinsic constructors even though they are genuine errors.These paths now use the SDK’s existing realm-tolerant
isErrorhelper. The fetch path additionally checkserror.name === "TypeError"to preserve its existing type restriction.Regression coverage creates errors in a separate Node VM context and exercises both core and browser event builders, aggregate and linked errors, and fetch instrumentation.
Fixes #22925