-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
meta(changelog): Update changelog for 7.99.0 #10405
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
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
[Gitflow] Merge master into develop
…attribute (#10274) To remove ambiguity and normalization logic in v8, we should only set the origin as an attribute, not as a top level option in the new startSpan APIs.
add known attribute keys to the `SpanAttributes` type because this way we can - enforce a concrete type for some known keys - provide auto suggestions when setting attributes
This adds a new hook to integrations which runs after all integrations have run their `setup` hooks. This can be used to handle integrations that depend on each other. The only timing guarantee is that `afterAllSetup` will be called after every integration has run `setupOnce` and `setup`.
…experimental` (#10259) This PR adds a test for `mysql2` auto instrumentation for `@sentry/node-experimental`. `mysql2` will not query unless there is a connection and it does not want to work without one like `mysql`. This PR adds a `withDockerCompose` method to the test runner which handles: - Starting the docker container - Waiting until some specific output has been seen from the container so we know the server is up - Closing and cleaning up the docker container/volumes ```ts createRunner(__dirname, 'scenario.js') .withDockerCompose({ workingDirectory: [__dirname], readyMatches: ['port: 3306'] }) .expect({ transaction: EXPECTED_TRANSACTION }) .start(done); ``` My only minor concern is that the mysql docker container creates a volume to store data. If the cleanup code does not run, a 180MB volume is left behind after every run. This will only be an issue when testing locally but we could start to fill developers machines. These can be cleaned up via `docker volume prune --force` but I would not want to run this on peoples machines without telling them!
I think this conditional needs to still call the deno cron `fn()`, and that we should do an early return if the client is **not** on `SETUP_CLIENTS`
Refactor deno integrations to functional style.
Extracted this out of #10327. This PR: * Introduces a new `browserTracingIntegration()` * Does NOT deprecate BrowserTracing yet, as custom implementations in Angular, Next, Sveltekit have not been migrated over yet, which would be weird. We can deprecate it once we moved these over. * Makes sure that custom implementations in Next & Sveltekit are "fixed" automatically * Uses a slim fork for the CDN bundles, to avoid shipping multiple implementations in there. * This means that in the CDN bundles, you can already use the new syntax, but you cannot pass a custom routing instrumentation anymore, and you also don't have the utility functions for it yet. I think this is the best tradeoff for now, and it's probably not a super common case to have custom routing instrumentation when using the Loader/CDN bundles (and if you do, you have to stick to `new BrowserTracing()` until v8). I copied the browser integration tests we have, which all pass!
…map (#10358) Auditing our integrations to make sure they work with the new client paradigm, also adding `export type` where appropriate.
To avoid capturing our own requests. See getsentry/spotlight#335
…10372) Noticed that this is not really correct right now!
Before submitting a pull request, please take a look at our [Contributing](https://github.com/getsentry/sentry-javascript/blob/master/CONTRIBUTING.md) guidelines and verify: - [x] Ensure your code lints and the test suite passes (`yarn lint`) & (`yarn test`). Closes #10362
As this comes up every now and then (e.g. #5108), I gather it makes sense to document how to build the SDK youself. I added a note to explicitly state that there are no guarantees there.
Looks like we missed re-exporting a couple of recently added functions in the Remix SDK. This patch adds the missing exports: * `addIntegration` * `getClient` * `getCurrentScope`, `getIsolationScope`, `getGlobalScope` * `setMeasurement` * `getActiveSpan` * `startSpan`, `startSpanManual`, `startInactiveSpan` * `continueTrace` * `isInitialized`
#10268) Deprecate the last remaining otel-incompatible API on the `Span` class and interface - `Span.setHttpStatus`. We replace this functionality with a `setHttpStatus` wrapper because in addition to setting the data/tag value (more on that below), this function also derives the span status from the status code. Added tests to make sure this is covered properly (I think it wasn't covered well before and we need to remove the old tests anyway).
Co-authored-by: Luca Forstner <[email protected]>
…tatusFromHttpCode` (#10361) The old export contained a typo/camel-case inconsistency which I fixed in the new export and I opted to prepend the `get` verb.
…ropagating and applying trace context (#10297)
…perimental` (#10382) Ref #9907 This actually tests `@hapi/[email protected]` because the latest v21 is not supported by the otel auto-instrumentation.
Introduce an e2e test that checks if all `@sentry/node` exports were re-exported in packages that depend on `@sentry/node`. It's not a real e2e test, as there's no actual test application, but we only execute a script that imports various SDKs depending on `@sentry/node`. However, IMO it makes a lot of sense to test the export of the final tarballs which we already have the infrastructure for in our e2e tests. see PR description for more details
…10393) This implements changes to the new integration, based on feedback from the team. The main thing this addresses is the way we disable the default span creation. The original idea was to make this work with custom router instrumentations (e.g. for react router) that may be added as separate integrations. This required us to keep track of if another, non-default implementation has been added, to opt out of the defaults. With this change, we do not do this anymore. Instead, the defaults should be configured by wrapping integrations. Some examples for how this should then work: 1. Angular: ```ts export function browserTracingIntegration( options?: Parameters<typeof originalBrowserTracingIntegration>[0], ): Integration { // do not use default navigation, as we provide our own // actual code for this is in the angular service options.instrumentNavigation = false; return originalBrowserTracingIntegration(options); } ``` 2. Vue ```ts export function browserTracingIntegration( options?: Parameters<typeof originalBrowserTracingIntegration>[0] & { router?: VueRouter }, ): Integration { if (options.router) { options.instrumentNavigation = false; const integration = originalBrowserTracingIntegration(options); const originalSetupAfterAll = integration.setupAfterAll; integration.setupAfterAll = (client: Client) => { setupVueRoutingInstrumentation(client); // some method originalSetupAfterAll(client); } } return originalBrowserTracingIntegration(options); } ``` 3. React ```ts export function browserTracingIntegration( options?: Parameters<typeof originalBrowserTracingIntegration>[0] & { router?: ReactRouterInstrumentation }, ): Integration { if (options.router) { options.instrumentNavigation = false; options.instrumentPageLoad = false; const integration = originalBrowserTracingIntegration(options); const originalSetupAfterAll = integration.setupAfterAll; integration.setupAfterAll = (client: Client) => { // setup custom routing instrumentation options.router(client); // or whatever API we want there originalSetupAfterAll(client); } } return originalBrowserTracingIntegration(options); } ```
This was a regression introduced with #10236, we shouldn't arbitrarily call `startInactiveSpan` given we create transactions under the hood currently.
This PR updates the serverless integrations to use the functional approach, and rewrites all of the serverless unit tests. In the unit test rewrite we remove the usage of global mocks and instead do per file mocks. I dislike the amount of mocks that still exist, but to prevent any regressions I only tried to translate the test code.
e4aa33e
to
77f7011
Compare
mydea
reviewed
Jan 30, 2024
mydea
reviewed
Jan 30, 2024
Adds missing re-exports from `@sentry/node` in the sveltekit server SDK and enables the re-export test for @sentry/sveltekit
Add missing exports from the Node to the Bun SDK. Ignored a couple of exports that I believe aren't compatible with Bun or for which we have dedicated Bun replacements (e.g. client, transport). Node would throw ESM/CJS errors when importing from `@sentry/bun`. So let's just use Bun for this test 🙃
Adds missing re-exports to the serverless package
10985c1
to
9a10a4e
Compare
Lms24
approved these changes
Jan 30, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rebased and updated changelog
…#10386) This introduces a new `onlyIfParent` option to the start-span APIs, which, if set, will ensure to not create a span if there is no parent. I've added this also for otel to demonstrate this works there as well. This PR also uses this option in a few places, esp. for http.client spans, to ensure we do not capture these if there is no ongoing transaction. This replaces https://github.com/getsentry/sentry-javascript/pull/10375/files with a more generic solution, and includes the test from #10376 (which passes here as well).
To make it easier to extend this.
Mention bug bounty program in our README
Co-authored-by: Luca Forstner <[email protected]>
…ils (#10410) So we can be client-safe when extending the integration.
Apply suggestions from code review
9a10a4e
to
818d959
Compare
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.
Need to get fixes out for #10364 and #10375 out asap.