-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
meta: CHANGELOG for 8.0.0-alpha.3 #11102
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
This is an important step towards aligning OTEL & Sentry Spans 🎉 You can see that the `Span` interface is now aligned enough that it accepts an OTEL span.
These exports were lost on the migration from the experimental package
…10814) On the road to deleting `Sentry.Integrations` exports - we remove all exports for `Sentry.Replay`, `Sentry.Feedback`, and `Sentry.ReplayCanvas`.
This can be used instead of `spanRecorder` going forward.
For now, this does not actually _use_ this anywhere. The idle span works _mostly_ like the idle transaction, but there are small differences: 1. I replaced the heartbeat with simply waiting for 15s (instead of 3x5s) after the last span was started. IMHO semantically this is good enough, and makes it easier to reason about this? LMK if I am missing something there. 2. This means that the idle span ends when either: a. No span was created for 1s b. The last time a span was created was 15s ago c. 30s passed (final timeout) 3. Instead of the `delayAutoFinishUntilSignal` we used before for e.g. Next.js streaming pages, we now have `disableAutoFinish`, together with `client.emit('idleSpanEnableAutoFinish', idleSpan)` 4. Idle spans are always on the scope (we never used it without this setting) 5. You can directly pass `beforeSpanEnd` (instead of `registerBeforeFinishCallback()`), which we can use for web vital collection etc.
…e` property (#10946) `Attachment.attachmentType` was changed to use a string union. The `attachment_type` header property should match so I added an extra type for this.
This PR adds the ability to override the client used for metrics rather than being tied to using the single client `getClient()` returns. ```ts Sentry.metrics.increment('counter', 1, { client }); ``` It also adds a `getMetricsAggregatorForClient` exported function which is required so the Electron SDK can access the current aggregator. `sendEnvelope` was added to the `Client` type so that all usages of `BaseClient<ClientOptions>` could be replaced with `Client`.
When tracing is disabled or otherwise skipped, they return a non recording span instead of undefined. This aligns the `startSpan`, `startSpanManual` and `startInactiveSpan` APIs with opentelemetry, where you also always get a span back.
Co-authored-by: Luca Forstner <[email protected]>
We don't have `@sentry/tracing` anymore, so that test can go.
`getCurrentScope()` has been changed to return the `Scope` interface rather than the `Scope` class. This means it's no longer possible to access `addScopeListener` on the returned scope. This PR adds this method to the interface. I also updated all the jsdocs in the class to use `@inheritDoc` so these docs aren't duplicated.
We've refactored all usage away, now we can actually get rid of the tags on the span themselves.
This was backported to v7 as part of #10964
we would like to start using node protocol imports in the SDK to unblock #10960 and #10928 This requires us to have a minimum supported Node version of `14.18.0` as per https://2ality.com/2021/12/node-protocol-imports.html
And remove idle transaction. With this, we can afterwards remove the span recorder, and everything related to it 🎉 I tried to keep all functionality intact. Some small cleanups I made: - idle span finish reason is kept as an attribute - to keep backwards compat I finally also write it as a tag on the transaction event - idle span trimming happens automatically now (no more `trimEnd` option - we always set this to true anyhow). However, this only applies when the span is auto-ended by the idle functionality, not if manually calling `span.end()` - which is fine IMHO because that will usually not happen for users, and even so it's not the end of the world. - We now use `continueTrace` for trace propagation of the pageload span. - no more `location` on the sampling context - we talked about this before, this is just gone, and users can instead either access the attributes from the sampling context, or just do `window.location.href` themselves, which should have the same outcome.
This also: * Fixes our prettier setup so it actually captures all files (and runs it on everything) * Updates node & node-experimental readmes to be correct There is still a lot missing but it's a start!
This is now always set as attribute.
For easier setup of error handling in fastify.
Some more node docs for v8, including: * How to add custom OTEL instrumentation * How to use with custom OTEL setup * How to setup non-framework node apps
closes #8887 docs changes: getsentry/sentry-docs#9422
This PR moves `defaultCurrentScope` and `defaultIsolationScope` to the `__SENTRY__` global.
The TypeScript docs say > `allowSyntheticDefaultImports` without `esModuleInterop` should be avoided. It changes the compiler’s checking behavior without changing the code emitted by tsc, allowing potentially unsafe JavaScript to be emitted. Additionally, the checking changes it introduces are an incomplete version of the ones introduced by `esModuleInterop`.
ref #9956 Given Bun is just a wrapper over Node, we should be good to go with just these changes.
This does two things: 1. Remove an unused remix integration test 2. Add a test that ensures we send correct server & browser transactions that are correctly linked I extracted these out from #11031, to ensure this is/remains stable before we migrate and after. (Side note: Once v8 is somewhat settled, we should really find a way to extract these event proxy things into a util 😅 )
This makes parsing logs for errors etc. harder than it needs to be. I already added this for node integration tests, but IMHO it makes sense for all jest tests on CI.
OK, this was a tricky one, but I _think_ it now works as expected. This PR fixes to fundamental issues with sampling & propagation that were uncovered by @Lms24 & myself while trying to use OTEL for remix & sveltekit: 1. `continueTrace` updates the propagation context, but if there is an active parent span (even a remote one) this is ignored. 2. Sampling inheritance did not work as expected, due to the fact that OTEL spans cannot differentiate between `sampled=false` (sampled to be not recorded) and `sampled=undefined` (no sampling decision yet). ## Update to `continueTrace` & trace propagation While my first instinct was to ensure that in the trace methods, if we have remote span we ignore it and look at the propagation context, this has a bunch of problems - because it means we can run out of sync, if this is set from outside, etc. So instead, I now provide a custom `continueTrace` method from `@sentry/opentelemetry` & `@sentry/node` which should be used instead of the core one in meta SDKs. This method will, in addition to updating the propagation context, _also_ create a remote span with the passed in data, and make it the active span in the callback. Then, I updated the otel start span APIs to always use that, if it exists (which was already the behavior we had), PLUS also added behavior that if there is no active span at all (not even a remote one), _then_ we look at the propagation context. ## Update to sampling inheritance Previously, we basically did the following: ```ts const sampled: Boolean | undefined = spanContext.traceFlags === TraceFlags.SAMPLED; // this will always be true or false, never undefined ``` Which means that if we create a remote span from a minimal propagation context: ```ts // This could be a generated propagation context from a scope const propagationContext = { spanId: 'xxx', traceId: 'yyy' }; const spanContext: SpanContext = { sampled: propagationContext.sampled ? TraceFlags.SAMPLED : TraceFlags.NONE, } ``` We would later always get `sampled: false`, and inherit this decision for all downstream spans - instead of treating it as `undefined`, and going through the sampler, as we actually want it to. In order to "solve" this, I added a new trace state `SENTRY_TRACE_STATE_SAMPLED_NOT_RECORDING`, which we set if we _know_ this is actually `sampled: false`, and not just unset. Then, based on this we can interpret `sampled` as being `false` or `undefined`, respectively. This is a bit hacky but should work - it means that if we get a sampling decision from outside we'll treat it as `undefined`, which is OK I would say. Our own sampler will set this correctly so we inherit correctly as well, and our propagator does so too. --------- Co-authored-by: Lukas Stracke <[email protected]>
This PR updates Rollup to v4 and updates all the plugins to their latest versions. When testing bundling of the new otel powered Node SDK, there are runtime errors caused by ESM/CJS interoperability. There have been plenty of issues fixed around this in both Rollup and the CommonJs plugin so we need to update. The changelog doesn't do justice for how much of a pain this was. Co-authored-by: Francesco Novy <[email protected]>
This updates the Remix SDK to use the new OTEL-powered `@sentry/node` under the hood.
Replace the current screenshot package with a new package that has screenshots and uses Preact for better readability. It will also allow for lazy loading in the future. Co-authored-by: Billy Vong <[email protected]> Co-authored-by: Ryan Albrecht <[email protected]> Co-authored-by: Abhijeet Prasad <[email protected]>
|
mydea
approved these changes
Mar 14, 2024
3c596fb
to
4c55c85
Compare
4c55c85
to
2a2ad1b
Compare
one day the tests will pass |
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.
Rendered changelog: https://github.com/getsentry/sentry-javascript/blob/abhi-changelog-8.0.0-alpha.3/CHANGELOG.md