CLOSED - add node support for generic featureFlagsIntegration and move utils to core #16537
Conversation
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
size-limit report 📦
|
…rt, sveltekit (has *)
aliu39
force-pushed
the
aliu/move-ffs-to-core
branch
from
e3470e2 to
868cd71
Compare
aliu39
changed the title
aliu39
changed the title
❌ Unsupported file format
|
This patch changes the `node` export in the `package.json` file to include an `import` version (similar to the other exports) to fix sveltejs/kit#13869 . In SvelteKit, we're now bundling dependencies on the server that specify SvelteKit as a dependency or peerDependency. This has caused an issue where builds with `@sentry/sveltekit` were being bundled incorrectly. Adding the `import` attribute fixes this so that Vite resolves to the ESM build of Sentry. --------- Co-authored-by: Lukas Stracke <lukas.stracke@sentry.io>
This PR adds the external contributor to the CHANGELOG.md file, so that they are credited for their contribution. See #16528 Co-authored-by: Lms24 <8420481+Lms24@users.noreply.github.com>
meta(changelog): Update changelog for 9.28.1
turns out repo-wide auto formatting (`yarn fix:prettier` in the root) changed some files here causing unrelated changes in other PRs. Also I added lint and fix commands to this package.
This deprecates the `ignoreEmberOnErrorWarning` option, as it is no longer used. Previously, we logged a warnining if we detected that this was used. But the option is now deprecated/will be removed, and since there is no real logic attached to this we can simply remove this (as well as the usage of the global `Ember` namespace) to avoid deprecations. Closes #16504 --------- Co-authored-by: Lukas Stracke <lukas.stracke@sentry.io>
[Gitflow] Merge master into develop
This changes the behavior of `suppressTracing` to be less problematic
(or, problematic in a different way).
Today, because in the browser we do not have async context isolation,
there is only a single shared top scope. Because of this, if you have
code like this:
```js
const spanPromise = suppressTracing(async () => {
await new Promise(resolve => setTimeout(resolve, 100));
return startInactiveSpan({ name: 'span' });
});
const span = startInactiveSpan({ name: 'span2' });
```
The span2 will also be suppressed, because `suppressTracing` forks the
scope and sets data on it to ensure spans are not recorded. This is
problematic as that will result in completely unrelated spans, e.g.
pageload/navigation spans, being suppressed while e.g. an ongoing fetch
call that is suppressed happens.
This PR changes this to instead only suppress tracing synchronously in
the browser. This obviously is also not really ideal and can lead to
things _not_ being suppressed, but it feels like the better tradeoff for
now.
billyvg
reviewed
Jun 11, 2025
| }); | ||
| }, | ||
|
|
||
| processEvent(event: Event, _hint: EventHint, _client: Client): Event { | ||
| return copyFlagsFromScopeToEvent(event); | ||
| return _INTERNAL_copyFlagsFromScopeToEvent(event); |
There was a problem hiding this comment.
@AbhiPrasad can we do this as part of our default event processing pipeline instead of having to define it for each integration?
There was a problem hiding this comment.
if the bundle size hit isn't too bad I'd be fine with moving it into event processing. Can we check that?
Otherwise we can also just add new client hooks for this.
There was a problem hiding this comment.
Where are the default processors defined? Would it be on the global scope, or client?
There was a problem hiding this comment.
@aliu39 let's follow-up with that, no need to block this PR on it
There was a problem hiding this comment.
Where are the default processors defined? Would it be on the global scope, or client?
on the client
By default, the instrumentation will register span processors only when
the ai package is used. This is done to avoid overhead of span
processing for users that do not even use this package.
However, it seems that in some environments, esp. in Next.js, the
instrumentation is not added correctly, thus never running this, and not
converting spans correctly. For now, this PR adds an escape hatch to
manually opt-in to this to still get correct spans:
```js
vercelAiIntegration({ force: true })
```
…16553) ref https://linear.app/getsentry/issue/FE-503/investigate-nested-middleware-spans-in-webfx-koa-application The Koa integration in `@sentry/node` was updated to expose the `ignoreLayersType` option from `@opentelemetry/instrumentation-koa`, aligning its configuration with the GraphQL integration. https://www.npmjs.com/package/@opentelemetry/instrumentation-koa <span><div class="markdown-heading"><h3 class="heading-element">Koa Instrumentation Options</h3><a id="user-content-koa-instrumentation-options" class="anchor" aria-label="Permalink: Koa Instrumentation Options" href="https://www.npmjs.com/package/@opentelemetry/instrumentation-koa#koa-instrumentation-options"></a></div></span><span> Options | Type | Example | Description -- | -- | -- | -- ignoreLayersType | KoaLayerType[] | ['middleware'] | Ignore layers of specified type. requestHook | KoaRequestCustomAttributeFunction | (span, info) => {} | Function for adding custom attributes to Koa middleware layers. Receives params: Span, KoaRequestInfo. <p><code>ignoreLayersType</code> accepts an array of <code>KoaLayerType</code> which can take the following string values:</p> <ul> <li> <code>router</code>,</li> <li> <code>middleware</code>.</li> </ul></span> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>
…16558) A new "Debugging Tests" section was added to `dev-packages/node-integration-tests/README.md`. This section documents the `DEBUG` environment variable, which enables verbose logging for the integration test suite. When `DEBUG=1` is set (e.g., `DEBUG=1 yarn test`), the test runner provides detailed output, including: * Test scenario startup information (path, flags, DSN). * Docker Compose output when tests use `withDockerCompose`. * Child process stdout and stderr. * HTTP requests made during tests. * Process errors and exceptions. * Line-by-line output from test scenarios. This addition improves discoverability and understanding of the debugging capabilities, aiding in troubleshooting failing tests and analyzing test execution flow. --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Bump vendored `web-vitals` library. Important changes from the original library: - For now until the next SDK major, we'll keep reporting FID. `web-vitals` removed the already deprecated APIs for it in v5 but we simply keep them from v4 - `web-vitals` further removed compatibility for older iOS Safari versions. Unfortunately, [we still support Safari 14.4 ](https://docs.sentry.io/platforms/javascript/troubleshooting/supported-browsers/) which is the last version that doesn't yet fully support the `visibilitychange` event. This requires us to keep the `onHidden` helper around which also listens to `pagehide` events that this Safari version supports. I adjusted our integration tests to keep one around that fails if we remove this special handling in a future upgrade (also added some context for future us). I will follow up with at least one more PR to do some more refactorings but I decided to keep them minimal in this PR to get better diffs for reviewing: - rename the `get*` files to `on*`, since this is how they're named now in the official library closes #16310
This PR fixes a bug discovered in #16486 (comment) where the root component span would not end correctly if `trackComponents` was `false`. Also added a comment to explain the purpose of the root component `ui.vue.render` span. We might want to look into renaming or removing this span in the future but for now, let's fix the behaviour.
1. Pins `minimatch` in nestjs-11 E2E test app -See nestjs/nest#15273. We can drop this when we bump node to 20.19.0, but for now this should be fine. 2. Pin trpc for nextjs-t3 E2E test app to 11.3.0 - See trpc/trpc#6821
meta(changelog): Update changelog for 9.29.0
…16566) Extracted out from #16565 I noticed that our `modulesIntegration` is pretty limited: 1. It does nothing on EMS 2. It does not work on Next.js (even though that is CJS) This PR makes this a bit more robust (not perfect): 1. It generally now also tries to look at `process.cwd() + 'package.json'` and take the dependencies and devDependencies from there. this should generally work in esm apps now as well, at least at a basic level. You do not get all dependencies and versions may be ranges, but better than nothing. 2. For Next.js, we inject a modules list based off the package.json at build time, as we do not have proper access to this at runtime.
[Gitflow] Merge master into develop
…le is detected (#16565) This PR improves the handling of the `ai` instrumentation to always be enabled when we detect the `ai` module is installed. For this, we leverage the `modulesIntegration`. This PR should make usage of ai instrumentation in Next.js "automatically" again - BUT users will have to specific ` experimental_telemetry: { isEnabled: true },` at each call manually for the time being. --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>
…16557) resolves #16237 In #16348 we had to revert the PR that added `detail` to `measure` spans as attributes. measure API: https://developer.mozilla.org/en-US/docs/Web/API/Performance/measure detail: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceMeasure/detail This was [reverted](#16347) because it was causing issues in firefox, specifically this error was being thrown ``` Error: Permission denied to access object at _addMeasureSpans(../../node_modules/@sentry-internal/browser-utils/build/esm/metrics/browserMetrics.js:255:41) at X2e/<(../../node_modules/@sentry-internal/browser-utils/build/esm/metrics/browserMetrics.js:194:9) at addPerformanceEntries(../../node_modules/@sentry-internal/browser-utils/build/esm/metrics/browserMetrics.js:174:48) at idleSpan.beforeSpanEnd(../../node_modules/@sentry/browser/build/npm/esm/tracing/browserTracingIntegration.js:90:9) at span.endapply(../../node_modules/@sentry/browser/node_modules/@sentry/core/build/esm/tracing/idleSpan.js:52:9) at Coe/<(../../node_modules/@sentry/browser/node_modules/@sentry/core/build/esm/tracing/idleSpan.js:196:12) at sentryWrapped(../../node_modules/@sentry/browser/build/npm/esm/helpers.js:38:17) ``` From debugging, this seems to be coming from a `DOMException` being thrown @https://developer.mozilla.org/en-US/docs/Web/API/DOMException This was re-implemented, and then we added tests to validate that this wouldn't break on firefox. --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>
aliu39
changed the title
|
Reopened at #16585 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
featureFlagsIntegrationis an integration to manually buffer feature flags on evaluation, and capture them in event contexts and span attributes. This PR moves it from browser to core, as well as the shared functionality/utils of all FF integrations (no browser specific logic).Browser exports and functionality is unchanged. Per @AbhiPrasad 's recommendation I've manually exported the integration in all the packages
zodErrorsIntegrationis exported. Note many backend pkgs use a wildcard (*) export from node.TODO:
Part of