meta(changelog): Update changelog for 7.69.0 by AbhiPrasad · Pull Request #9009 · getsentry/sentry-javascript

AbhiPrasad · 2023-09-12T19:25:03Z

@malay44 your changes will be released in 7.69.0!

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.

…pt (#8985)

Replace ts-ignore with ts-expect-error

…rrors` (#8986)

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(); }); ```

…lStorage (#9006)

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.

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

lforst

nice

AbhiPrasad · 2023-09-12T19:25:03Z

@malay44 your changes will be released in 7.69.0!

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.

…pt (#8985)

Replace ts-ignore with ts-expect-error

…rrors` (#8986)

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(); }); ```

…lStorage (#9006)

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.

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

lforst

nice

AbhiPrasad · 2023-09-12T19:25:03Z

@malay44 your changes will be released in 7.69.0!

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.

…pt (#8985)

Replace ts-ignore with ts-expect-error

…rrors` (#8986)

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(); }); ```

…lStorage (#9006)

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.

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

lforst

nice

AbhiPrasad · 2023-09-12T19:25:03Z

@malay44 your changes will be released in 7.69.0!

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.

…pt (#8985)

Replace ts-ignore with ts-expect-error

…rrors` (#8986)

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(); }); ```

…lStorage (#9006)

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.

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

lforst

nice

AbhiPrasad · 2023-09-12T19:25:03Z

@malay44 your changes will be released in 7.69.0!

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.

…pt (#8985)

Replace ts-ignore with ts-expect-error

…rrors` (#8986)

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(); }); ```

…lStorage (#9006)

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.

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

lforst

nice

AbhiPrasad · 2023-09-12T19:25:03Z

@malay44 your changes will be released in 7.69.0!

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.

…pt (#8985)

Replace ts-ignore with ts-expect-error

…rrors` (#8986)

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(); }); ```

…lStorage (#9006)

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.

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

lforst

nice

AbhiPrasad · 2023-09-12T19:25:03Z

@malay44 your changes will be released in 7.69.0!

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.

…pt (#8985)

Replace ts-ignore with ts-expect-error

…rrors` (#8986)

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(); }); ```

…lStorage (#9006)

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.

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

lforst

nice

AbhiPrasad · 2023-09-12T19:25:03Z

@malay44 your changes will be released in 7.69.0!

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.

…pt (#8985)

Replace ts-ignore with ts-expect-error

…rrors` (#8986)

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(); }); ```

…lStorage (#9006)

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.

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

lforst

nice

mydeaand others added 30 commits September 6, 2023 13:53

fix(nextjs): Request for no HSTS in tunnel route endpoint (#8936)
3076e09

Merge pull request#8959from getsentry/master
66a925e
[Gitflow] Merge master into develop

feat(nextjs): RemoveEdgeClientand useServerRuntimeClient(#8932)
d3fe473
This PR removes the `EdgeClient` and duplicate `eventbuilder` functions.

fix(node-experimental): Use Sentry logger as Otel logger (#8960)
dad475c
So the logs are properly hidden from breadcrumbs etc.

fix: uuidv4 fix for cloudflare (#8968)
fbe1b78

ref(core): Introduce protected_getBreadcrumbs()on scope (#8961)
4c17f6e
Making it easier to potentially change this e.g. for POTEL.

fix(remix): Addglobto Remix SDK dependencies. (#8963)
843c072

chore(e2e): Use Node 18 for E2E tests. (#8964)
eafe791

feat(remix): Accept org, project and url as args to upload scri…
4278a71
…pt (#8985)

ref: Remove all usages of ts-ignore (#8974)
f63b33b
Replace ts-ignore with ts-expect-error

fix(core): Always use event message and exception values for `ignoreE…
b190015
…rrors` (#8986)

ref: Cleanup lint warnings (#8972)
6f97b5f
This pollutes the console when running the linter, hopefully also speeds up CI a little bit.

feat(eslint): Enforce that ts-expect-error is used (#8987)
d3c3462
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/

fix(overhead-metrics): Remove unneeded@ts-expect-error(#8990)
2ab1f50
Should fix failing CI on develop rn.

fix(replay): Fully stop & restart session when it expires (#8834)
30c4540
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.

build(lint): Remove unneeded@ts-expectcomments (#8995)
f63036b
Noticed warnings for this during build.

fix(node-experimental): Ignore outgoing Sentry requests (#8994)
9e39717
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.

feat(redux): Add 'attachReduxState' option (#8953)
595e4e2
Co-authored-by: Abhijeet Prasad <devabhiprasad@gmail.com>

fix(nextjs): Add new potential location for Next.js request AsyncLoca…
5a42bd9
…lStorage (#9006)

fix(node-experimental): Require parent span forpgspans (#8993)
d16f819

fix(react): Switch to props inuseRoutes(#8998)
47d0c89

feat(core): ExportBeforeFinishCallbacktype (#8999)
868a3cd

ref: Avoid unnecessaryhub.getScope()checks (#9008)
a7f5911
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.

mydeaand others added 4 commits September 12, 2023 16:11

fix(node-experimental): Ignore OPTIONS & HEAD requests (#9001)
0e23d4d
Similar to express, we want to ignore (incoming) OPTIONS & HEAD requests.

chore(ts): Add TS3.8 compile test (#8955)
cfc2333

feat(node-experimental): Keep breadcrumbs on transaction (#8967)
789e849

AbhiPrasad requested review from a team, lforst and mydea and removed request for a teamSeptember 12, 2023 19:25

fix(utils): Prevent iterating over VueViewModel (#8981)
90ee2a4
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 5dfdf5fCompare September 13, 2023 06:53

mydea reviewed Sep 13, 2023
View reviewed changes

Comment threadCHANGELOG.md Outdated

meta(changelog): Update changelog for 7.69.0
1768ba0

mydea force-pushed the prepare-release/7.69.0 branch from 0c0c53e to 1768ba0Compare September 13, 2023 07:31

mydea approved these changes Sep 13, 2023
View reviewed changes

lforst approved these changes Sep 13, 2023
View reviewed changes

mydea merged commit 05583e5 into masterSep 13, 2023

mydea deleted the prepare-release/7.69.0 branch September 13, 2023 07:55