-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
meta(changelog): Update changelog for 10.11.0 #17570
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
Conversation
[Gitflow] Merge master into develop
We no longer use this, since we moved to linear. Noticed here: #17503 which is also closed by this.
…orsIntergation` (#17251) `type` now follows the[ trace origin](https://develop.sentry.dev/sdk/telemetry/traces/trace-origin/) naming scheme. Omitted `data.function` in favour of more specific types. see #17212 closes #17250
Something 5.0.31 causes weird errors around `msw` not being found. Potentially related: vercel/ai#8469
The NestJS SDK didn't add a mechanism to a bunch of caught errors. This resulted in the errors being incorrectly marked as `handled: true` and the `mechansim.type` defaulting to `'generic'`. This patch: - adds the mechanism to all `captureException` calls within the SDK, marking caught exceptions as `handled: false` - reviewers: Please let me know if any of these should in fact be `handled: true`! - adds a specific `mechanism.type`, following the naming scheme of [trace origin](https://develop.sentry.dev/sdk/telemetry/traces/trace-origin/) - adjusts and adds test assertions so that we actually test on the expected mechanism
…openAiIntegration` (#17288) Also changes the `sentry.origin` attribute to from `auto.function.openai` to `auto.ai.openai` since `ai` is the widely used category for these spans. (this was added initially via #17288) `mechanism.type` now follows the same pattern trace origin pattern. ref #17212 ref #17252
…17535) This PR enhances Anthropic AI instrumentation to properly handle and record errors that occur as part of response metadata. Core Error Handling Improvements: - Enhanced error detection: Added proper handling for Anthropic API error responses with type: 'error' structure - Improved streaming error handling: Better error type detection and reporting for streaming operations - Error capturing: Manually captured errors for both standard and streaming errors
We only need to use the `link:...` syntax in E2E tests which are not in the workspace. Also cleans up some other deps that somehow are not in sync in yarn.lock...?
#17525) This introduces a new experimental Sentry Lambda extension within the existing Sentry Lambda layer. Sentry events are being tunnelled through the extension, where they are then forwarded to Sentry. Initial benchmarks using ApacheBench show a reduction in request processing time of around 26% (from 243ms to 180ms on average over 100 requests; function pre-warmed). To enable it, set `_experiments.enableLambdaExtension` in your Sentry config like this: ```js Sentry.init({ // ...other config dsn: "<YOUR_DSN>", _experiments: { enableLambdaExtension: true } }) ``` closes #12856 relates to #3051
…17536) This refactors the astro middleware a bit to be more correct & future proof. Right now, http.server spans are not emitted by the node http integration because import-in-the-middle does not work with Astro. So we emit our own. This PR makes astro ready to also handle the base http.server spans and enhance them with routing information. It also handles static routes better: these do not emit spans anymore now, and do not continue traces, but instead only propagate the parametrized route to the client, no trace data. One fundamental problem remains that is not fixed in this PR: `Sentry.init()` is only injected via `page-ssr` into SSR pages. This means that only once any SSR page is hit, the server-side part of Sentry is initialized. If you hit a prerendered (static) page first, sentry will not be initialized and thus neither errors are captured nor spans created. For regular prerendered pages this should be fine because we do not need to run anything at runtime there. However, when you hit a prerendered page that has a server-island, the server island (which is dynamic) will not be instrumented either because Sentry is not initialized yet. I don't think we can fix this with the current set of primitives we have, so this is a future problem to look into... --------- Co-authored-by: Lukas Stracke <[email protected]>
Noticed here: https://github.com/getsentry/sentry-javascript/actions/runs/17542916888/job/49818463117 that this was not actually working 🤔 I played around a bit with this locally, and this change made it work for me. Not sure why the `path` part is not working as expected, but we filter for the correct changes anyhow below, so this should be fine IMHO.
It keeps happening that we have an out-of-date yarn.lock file, this should hopefully lint against this for the future 🤔 Failing here: https://github.com/getsentry/sentry-javascript/actions/runs/17545403486/job/49825686877?pr=17552
Removes recently introduced special-casing lazy-route -> lazy-route transaction name updates. This completes the fix in #17438. E2E tests are updated to replicate a similar case in the reproduction here: #17417 Also manually tested on the reproduction. --------- Co-authored-by: Sigrid Huemer <[email protected]>
…o 0.52.0 (#17557) Bumps [@opentelemetry/instrumentation-ioredis](https://github.com/open-telemetry/opentelemetry-js-contrib/tree/HEAD/packages/instrumentation-ioredis) from 0.51.0 to 0.52.0. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/packages/instrumentation-ioredis/CHANGELOG.md"><code>@opentelemetry/instrumentation-ioredis</code>'s changelog</a>.</em></p> <blockquote> <h2><a href="https://github.com/open-telemetry/opentelemetry-js-contrib/compare/instrumentation-ioredis-v0.51.0...instrumentation-ioredis-v0.52.0">0.52.0</a> (2025-09-08)</h2> <h3>Features</h3> <ul> <li><strong>deps:</strong> update otel deps (<a href="https://redirect.github.com/open-telemetry/opentelemetry-js-contrib/issues/3027">#3027</a>) (<a href="https://github.com/open-telemetry/opentelemetry-js-contrib/commit/fd9e262fabf4e8fd8e246b8967892fa26442968a">fd9e262</a>)</li> </ul> <h3>Dependencies</h3> <ul> <li>The following workspace dependencies were updated <ul> <li>devDependencies <ul> <li><code>@opentelemetry/contrib-test-utils</code> bumped from ^0.49.0 to ^0.50.0</li> </ul> </li> </ul> </li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/open-telemetry/opentelemetry-js-contrib/commits/instrumentation-pg-v0.52.0/packages/instrumentation-ioredis">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
size-limit report 📦
|
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
CHANGELOG.md
Outdated
|
||
### Other Changes | ||
|
||
- feat(aws): Add experimental AWS Lambda extension for tunnelling events ([#17525](https://github.com/getsentry/sentry-javascript/pull/17525)) |
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.
m: This is already covered above.
CHANGELOG.md
Outdated
- ref(browser): Add more specific `mechanism.type` to errors captured by `httpClientIntegration` ([#17254](https://github.com/getsentry/sentry-javascript/pull/17254)) | ||
- ref(browser): Set more descriptive `mechanism.type` in `browserApiErrorsIntergation` ([#17251](https://github.com/getsentry/sentry-javascript/pull/17251)) | ||
- ref(core): Add `mechanism.type` to `trpcMiddleware` errors ([#17287](https://github.com/getsentry/sentry-javascript/pull/17287)) | ||
- ref(core): Add more specific event `mechanism`s and span origins to `openAiIntegration` ([#17288](https://github.com/getsentry/sentry-javascript/pull/17288)) | ||
- ref(nestjs): Add `mechanism` to captured errors ([#17312](https://github.com/getsentry/sentry-javascript/pull/17312)) |
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.
q: Hm, aren't these user facing? We don't want them up there with other changes?
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.
They are marked as a refactor that's why I added them here 🤔
@Lms24 Should I add them to the "other changes"?
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.
These are user facing, yes. Yeah let's add them to other changes, thanks!
const buf = await buffer(req); | ||
// Extract the actual bytes from the Buffer by slicing its underlying ArrayBuffer |
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.
Potential bug: The Lambda extension uses await buffer(req)
to load the entire request body into memory without size validation, risking an out-of-memory crash when processing large Sentry envelopes.
-
Description: The request handler in the AWS Lambda extension uses
await buffer(req)
to load the entire incoming request body into memory before processing. Sentry envelopes can be large (up to 20MB compressed), especially with attachments or replay data. In a memory-constrained Lambda environment, which can be as low as 128MB, attempting to buffer a large payload without any size validation can exhaust available memory. This would lead to an out-of-memory error, causing the entire Lambda function to crash. This affects users with the experimentalenableLambdaExtension
feature enabled. -
Suggested fix: Before calling
await buffer(req)
, inspect thecontent-length
header of the incoming request. If the size exceeds a reasonable, safe threshold (e.g., 20MB), reject the request immediately with a413 Payload Too Large
status code instead of attempting to read the entire stream into memory.
severity: 0.65, confidence: 0.9
Did we get this right? 👍 / 👎 to inform future reviews.
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.
will investigate if this is relevant and send a follow-up PR if it is
) Extracting incoming request data to span attributes. It's a very long PR but most of it are test edits as the new http attributes are added to existing tests (otherwise, they would fail). Those are the most important changes: - add a function `httpHeadersToSpanAttributes` in core that is used for generating the attributes - adding extra logic in astro, bun, cloudflare, nextjs, remix and sveltekit (custom handler instrumentation) to include the attributes⚠️ There is one test in Next.js that fails when turbopack is enabled (see [diff snippet](https://github.com/getsentry/sentry-javascript/pull/17475/files#diff-a2882f52b1398a7c6f987463b5d38c375edd391bff5665cb82257e2280c8ffeeR26-R30)). As turbopack for build is still beta (in version v15.5.0), this test is excluded for now. Issue: #17568 Closes #17452
9744df6
to
91b13b6
Compare
No description provided.