meta(changelog): Update changelog for 7.82.0 #9661
Merged
Conversation
This file contains 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 can be used to replace some of our `setupOnce` hooks, and does not rely on global state.
Rename the onDialogOpen and onDialogClose callbacks to onFormOpen and onFormClose to match our defined terminology and remove onActorClick as it's not necessary. Closes #9605
We aren't actually using this anymore anywhere.
… load (#9622) This is a tricky one 😬 Basically, it is possible that fetch returns a readable stream that is ongoing. So if we do `await response.text()` this will be pending forever, if a stream is ongoing. I haven't found a way to really check that is the case and avoid parsing this at all 🤔 So the best I could come up with was to instead add a timeout of 500ms when we stop waiting for the fetch body. This should at least unblock waiting on this, but it will still mean that the response continues to be parsed client-side - I don't think there is a way to abort this 🤔 Additionally, this also refactors this a bit so we add a new `BODY_PARSE_ERROR` meta warning if the parsing of the body fails, for whatever reason. we may also use this in the replay UI cc @ryan953 somehow? "fixes" #9616
Inspired by recent comments about the continueTrace method, I figured we can actually update this in a backwards-compatible way to _also_ allow to use it without a callback.
This allows to pass `mechanism` as an event hint. Also, we now allow to pass `hint` as an alternative to `CaptureContext` to `captureException` as second argument. We have quite a lot of code where we fork a scope and add an event processor, only to add a mechanism to the event. Since this is a quite common pattern, I figured it makes more sense to allow to pass a mechanism as an EventHint. In addition, I noticed that while `hub.captureException()` takes an event hint as second argument, in the core exported `captureException()` we take a `CaptureContext` as second argument instead (for legacy reasons). In order to be able to pass a mechanism there as well, I updated the method signature to allow _either_ a CaptureContext _or_ an EventHint. I wrote some tests covering this to make sure that works - it's a bit tricky since both can be POJOs, but no fields overlap so we are able to parse this together.
This PR adds a new top level option called `spotlight` to Node init
options. Under the hood, if this option is true,
* all integrations will be forcefully initialized . This ensures that
without a DSN, we still capture and process events (but simply don't
send them to Sentry)
* a new `Spotlight` integration is added. This integration will make a
`http` post request to the sidecar URL. Either we take the default
sidecar URL or users provide their own URL:
```js
// enable/disable
Sentry.init({
spotlight: process.env.NODE_ENV === "development"
});
// enbale by setting a custom URL
Sentry.init({
spotlight: process.env.NODE_ENV === "development" ? 'http://localhost:7777' : false
});
```
This option should also work in Node Experimental, given that Node
experimental just calls the node init function.
---------
Co-authored-by: Lukas Stracke <lukas.stracke@sentry.io>
This can be used instead of `getCurrentHub().getClient()`. This prepares us also for a post-hub time, but makes sense generally IMHO, also simplifies user-facing interaction with the client (e.g. to lazy-add integrations etc). This is a 1-1 replacement, so should be pretty straightforward.
Adds an `onClose` callback to `showReportDialog`. The callback is invoked when a `__sentry_reportdialog_closed__` MessageEvent is received. This is sent from the error page embed via `window.postMessage` and listened to in the sdk.
#9542) This is mostly an internal utility, but changes a bit. The previous implementation for adding instrumentation had a few issues: * It was impossible to tree shake. So even if some instrumentation is never used, the whole code for it is always included. Splitting this up opens up future improvements there as well. * It was not type safe, and actually there _were_ some subtle issues in the code because of this - things could fail in unexpected ways, as we have been doing a lot of type casting from/to any etc. This PR splits up `addInstrumentationHandler` into e.g. `addFetchInstrumentationHandler` etc. methods, which improves the actual type safety a lot, because currently we've been duplicating the types everywhere, sometimes in slightly differing ways, leading to potential issues. **We had a bunch of issues with xhr & fetch data in Replay recently, so I figured it would finally be a good time to clean this up so we can ensure that the data we get is consistent & reliable.** Hopefully this change will prevent issues like we have/had in replay from popping up in the future. Some additional notes: * For the dom instrumentation, I picked the name `addClickKeypressInstrumentationHandler()`. I'm open for other naming ideas, but I found `addDomInstrumentation` a bit too broad, as this could mean a lot of things - and we are strictly only instrumenting clicks and keypresses here. Another name (if we want to be a bit broader) could be e.g. `addDomEventInstrumentation` or something like this? * I updated the type for the XHR data handler to make the method & url required. This was previously optional (but not in some of the code, where we expected this to always be), plus we also did not handle the case that `url` can be a `URL` instead of a string, which we now convert. * On the XHR data, we have one field `args` that 1. is not really used and 2. was actually "buggy", as we always returned the args, but for `open` and `send` the args are very different things (but we pretended it's always the "open" args). Now, this is actually always the method & url, and I also deprecated this for v8. * On the XHR data, we also had an unused/unset `data` field, which I removed (this was not set anywhere) * All old code should still work normally, but I deprecated the generic `addInstrumentationHandler()` method, for removal in v8. * I also took the opportunity and split the instrumentations into dedicated files, previously this was one mega-file which made it harder to reason about things.
There's a bug in some browsers that attaches huge resource sizes that are completely unrealistic. Here's an example in chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1324812#c25 To get around this, we add a filter to enforce that resource sizes should only be attached if the size is < 2147483647 bytes (size of maximum value of integer in c/c++).
…#9532) This change adds automatic registration of our Astro middleware. This is possible since Astro 3.5.2 by [adding middleware](https://docs.astro.build/en/reference/integrations-reference/#addmiddleware-option) entry points in the astro integration's setup hook. This is backwards compatible with previous Astro versions because we can simply check if the `addMiddleware` function exists and only make use of it if it does.
Remix documentation suggests users avoid capturing aborted requests.
Lms24
approved these changes
Nov 27, 2023
AbhiPrasad
reviewed
Nov 27, 2023
lforst
force-pushed
the
prepare-release/7.82.0
branch
3 times, most recently
from
6daf7ea
to
73b8bfb
Compare
size-limit report 📦
|
lforst
force-pushed
the
prepare-release/7.82.0
branch
from
73b8bfb
to
cf8cda8
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.
No description provided.