meta(changelog): Update changelog for 7.69.0 #9009
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
This is a micro improvement, but maybe worth it as we can have a lot of breadcrumbs. This ensures we only create a new breadcrumbs array if we exceed the limit. In contrast, currently we'll always create two copies of the breadcrumbs for each added breadcrumb (first for the array spread, then we copy it through the slice), even if we don't really need to do this.
[Gitflow] Merge master into develop
This PR removes the `EdgeClient` and duplicate `eventbuilder` functions.
So the logs are properly hidden from breadcrumbs etc.
Making it easier to potentially change this e.g. for POTEL.
As per the new changes in RFC 101 in getsentry/rfcs#113, update the span performance API names. - `startActiveSpan` -> `startSpan` - `startSpan` -> `startInactiveSpan` https://github.com/getsentry/rfcs/blob/main/text/0101-revamping-the-sdk-performance-api.md `startActiveSpan` is deprecated, while `startInactiveSpan` is being introduced. The breaking change is that `startSpan` is being changed, but considering that basically no-one is using the `startSpan` API, we should be fine to break here for correctness reasons. Better break now than to have everyone refactor their code in v8.
Replace ts-ignore with ts-expect-error
This pollutes the console when running the linter, hopefully also speeds up CI a little bit.
#8988) There was some confusion about this because the migration doc in this repo conflicts with the `highly experimental` tag we put on the README. Also added Node 18+ requirements. We can change this in migr8 for a future release, but for now let's merge this in to reduce confusion and unblock our users.
Enforce that `@ts-expect-error` is used instead of `@ts-ignore`. This is done by updating the `typescript-eslint/ban-ts-comment` rule. https://typescript-eslint.io/rules/ban-ts-comment/
Should fix failing CI on develop rn.
#8966) This is a fork of #8937, with only the "uncontroversial" stuff, mainly fixing that we only create HTTP breadcrumbs for _outgoing_ requests. In addition, this also migrates to using `requestHook` and `responseHook` instead of `applyCustomAttributesOnSpan`. We may have to revisit this later, but these hooks seem to have a better context awareness (=they are called in a more reasonable OTEL context, which gives the callbacks there better access to scope data etc). However that means we cannot (easily) pass both request and response as breadcrumb hints - not sure how important that is to us... For now I'd say that's OK. Note that also `requestHook` is only called when the request finishes, so we already have all the response OTEL span attributes correctly set there.
This PR changes the behavior when a session is expired to fully stop & restart the replay. This means we just re-sample based on sample rates and start a completely new session in that case.
…ded (#8938) I noticed that in `handleRecordingEmit`, due to the async nature of `addEvent` it could happen that an event is actually not added (because it is discarded due to timestamp etc.). But we are still updating the initial session timestamp (`[Replay] Updating session start time to earliest event in buffer to...`), as we don't actually abort there. This PR changes this to actually abort `handleRecordingEmit` in this case. I added an `addEventSync` method for this that just returns true/false instead of a promise, which should not change anything there as we haven't been waiting for the result of the promise anyhow.
Noticed warnings for this during build.
We do filter these out in the span processor, but we can avoid all this work by not even generating OTEL spans at all for outgoing Sentry requests.
…event processors (#8956) While looking through our existing integrations, I noticed that the `LinkedErrors` integration in node had some weird/custom code to manually run the context lines integration after it processed, as we cannot guarantee any order etc. I figured it would be much cleaner to solve this with a proper hook (I went with `preprocessEvent`), as it actually makes sense for this to generally run before all other event processors run, IMHO, and we can decouple these integrations from each other.
Co-authored-by: Abhijeet Prasad <devabhiprasad@gmail.com>
Based on #8911 and convos in slack, it was brought up that we might need to expose a method that works similar to `startSpan`, but that does not automatically finish the span at the end of the callback. This is necessary when you have event emitters (`res.once`) or similar. ```ts Sentry.startSpanManual(ctx, (span, finish) => { // do something with span // when you're done, call finish() finish(); }); ```
We've changed this some time ago so that `hub.getScope()` _always_ returns a scope, so we can actually update our code where we still check for the existence of scope.
This PR updates the span reference cleanup to take into account if a span is/may still be referenced somewhere else. Previously, whenever a span finished we removed the reference from the map, to clean up and avoid memory leaks. However, it seems that sometimes spans are ended before a child span is started (at least the hooks may fire in this order). This leads to the potential case where a parent that _should_ exist cannot be found, thus creating a new transaction instead of a span. With this change, we keep more information in our span map, in order to clear sub-spans (=not transactions) only when the root span (=transaction) is finished.
Similar to express, we want to ignore (incoming) OPTIONS & HEAD requests.
AbhiPrasad
requested review from
a team,
mydea and
lforst
and removed request for
a team
Prevent stringifying VueViewModel objects which causes a warning when the object is logged to console. Instead, normalize it's string value to `"[VueViewModel]"` More details in #8980
Lms24
force-pushed
the
prepare-release/7.69.0
branch
from
22754ca to
5dfdf5f
Compare
mydea
reviewed
Sep 13, 2023
mydea
force-pushed
the
prepare-release/7.69.0
branch
from
0c0c53e to
1768ba0
Compare
mydea
approved these changes
Sep 13, 2023
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.
@malay44 your changes will be released in
7.69.0!