-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
meta: CHANGELOG for 8.8.0 #12393
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
meta: CHANGELOG for 8.8.0 #12393
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
We're currently attempting to manually update the Hapi route transaction status, followed by `.end()` call. Looking at `@opentelemetry/instrumentation-hapi`s code, it looks like that is [already covered by the underlying instrumentation](https://github.com/open-telemetry/opentelemetry-js-contrib/blob/27d6503089163a3d1ed85687cd8e0bc43f525fdd/plugins/node/opentelemetry-instrumentation-hapi/src/instrumentation.ts#L395-L402). This PR removes that, also extends tests to make sure the error events and the transactions are linked properly.
To use this integration: ```javascript import * as Sentry from "@sentry/solidjs"; import {Route, Router, useBeforeLeave, useLocation} from "@solidjs/router" Sentry.init({ dsn: <dsn> integrations: [ Sentry.solidRouterBrowserTracingIntegration({ useBeforeLeave, useLocation }), ], tracesSampleRate: 1.0, // Capture 100% of the transactions debug: true, }); const SentryRouter = Sentry.withSentryRouterRouting(Router) render(() => ( <SentryRouter> // ... routes here // <Route .../> </SentryRouter> ), root!); ```
…12294) The error that folks are getting is something like this: `[Error] TypeError: null is not an object (evaluating 'qo.body.appendChild')` The problem seems to be that we're trying to inject the button into the html before the `<body>` is ready. Using async `<script defer>` or `<script async>` would probably help, but none of our snippets have that, and it would also defer error observers and everything else. What we can do for users it have the feedback integration wait before inserting the button + styles! This is a great reference: https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event Fixes #12112
Recreating #11151 for v8 again, as the updates seem to be lost when moving the instrumentation inside the project structure. The testing updates introduced in the original PR do exist in develop / master, so this PR only reintroduces changes in the instrumentation code.
Co-authored-by: Andrei <168741329+andreiborza@users.noreply.github.com>
I noticed here https://github.com/getsentry/sentry-javascript/pulls that some tests were becoming flaky. Investigating this some more, I figured out what was happening: 1. For idle spans, when the span is ended (in `on('spanEnded')`, which is triggered in `span.end()`), we call `onIdleSpanEnded` 2. In there, we call `beforeSpanEnd` 3. This is used by `browserTracingIntegration` to call `addPerformanceEntries(span)`, which adds performance spans to the idle span 4. After that, in `onIdleSpanEnded`, any spans having start/end timestamps outside of the idle span start/end timestamp will be discarded This lead to cases where performance spans were discarded because they were out of bounds of the idle span - which is not what we want! Now, this PR changes the timing of this a bit: Now, we actually patch `span.end` of the SentrySpan, to ensure that we can always run `beforeSpanEnd` with the correct timing, taking all spans that are added in `beforeSpanEnd` into account to adjust the start/end time of the idle span.
Re-use this for playwright config in E2E tests. Now, instead of repeating the whole playwright config, we can import the util from `@sentry-internal/test-utils` and pass it some config. I left the places where do not yet use the proxy, because for simplicity I built the util in a way that assumes the proxy (you can override it, but I figured not worth it for stuff that we will refactor soon anyhow). While at it, I also streamlined the playwright version used everywhere to an up-to-date version.
When using `_experiments.traceInternals`, this could lead to an infinite loop, as we run this check when a breadcrumb is added, and we add this breadcrumb in the check, ... Fixes #12283
Part of #11910 - we already have error & transaction tests there, so we can just delete the sending tests.
Add an e2e (or rather integration) test for our AWS lambda layer bundle. The motivation for this test is that we broke the layer during the initial v8 releases (multiple times for different reasons) without us noticing this in tests. Simply because we never tested the bundled SDK code that we create and publish for the lambda layer.
…ientTraceMetadata` option (#12323) Co-authored-by: Luca Forstner <luca.forstner@sentry.io>
Bumps [pnpm/action-setup](https://github.com/pnpm/action-setup) from 2 to 4. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/pnpm/action-setup/releases">pnpm/action-setup's releases</a>.</em></p> <blockquote> <h2>v4.0.0</h2> <p>An error is thrown if one version of pnpm is specified in the <code>packageManager</code> field of <code>package.json</code> and a different version is specified in the action's settings <a href="https://redirect.github.com/pnpm/action-setup/pull/122">#122</a></p> <h2>v3.0.0</h2> <p>The action is updated to run on Node.js v20</p> <h2>v2.4.0</h2> <p>Add ability to install standalone binary (<a href="https://redirect.github.com/pnpm/action-setup/pull/92">pnpm/action-setup#92</a>).</p> <h2>v2.3.0</h2> <ul> <li>feat: specifying path to non-root <code>package.json</code> file (<a href="https://redirect.github.com/pnpm/action-setup/pull/88">pnpm/action-setup#88</a>).</li> <li>docs: improve.</li> </ul> <h2>v2.2.4</h2> <p>No deprecation warnings are printed about set-state and set-output commands (<a href="https://redirect.github.com/pnpm/action-setup/issues/57">pnpm/action-setup#57</a>)</p> <h2>v2.2.3</h2> <p>Bump Node.js version to 16 <a href="https://redirect.github.com/pnpm/action-setup/pull/56">pnpm/action-setup#56</a></p> <h2>v2.2.2</h2> <p>Fixing network issues.</p> <p>Related issues:</p> <ul> <li><a href="https://redirect.github.com/pnpm/action-setup/issues/44">pnpm/action-setup#44</a></li> <li><a href="https://redirect.github.com/pnpm/action-setup/issues/22">pnpm/action-setup#22</a></li> </ul> <p>Related PR:</p> <ul> <li><a href="https://redirect.github.com/pnpm/action-setup/pull/46">pnpm/action-setup#46</a></li> </ul> <h2>v2.2.1</h2> <p>Fix <code>"packageManager"</code> reader <a href="https://redirect.github.com/pnpm/action-setup/pull/35">pnpm/action-setup#35</a></p> <h2>v2.2.0</h2> <ul> <li>Support the <code>packageManager</code> field in the <code>package.json</code> file <a href="https://redirect.github.com/pnpm/action-setup/pull/33">pnpm/action-setup#33</a>.</li> <li>Use <code>@pnpm/fetch</code> as an attempt to fix <a href="https://redirect.github.com/pnpm/action-setup/issues/22">pnpm/action-setup#22</a> <a href="https://redirect.github.com/pnpm/action-setup/pull/32">pnpm/action-setup#32</a>.</li> </ul> <h2>v2.1.0</h2> <p>Support pnpm v7 <a href="https://redirect.github.com/pnpm/action-setup/pull/29">pnpm/action-setup#29</a></p> <h2>v2.0.1</h2> <p>Update versions in code examples in README.md to the latest ones to avoid users using the wrong versions.</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/pnpm/action-setup/commit/fe02b34f77f8bc703788d5817da081398fad5dd2"><code>fe02b34</code></a> docs: bump action-setup version in README</li> <li><a href="https://github.com/pnpm/action-setup/commit/bee1f099e575ebe79c239f210b7b841a7597f87b"><code>bee1f09</code></a> feat: throw error when multiple versions specified (<a href="https://redirect.github.com/pnpm/action-setup/issues/122">#122</a>)</li> <li><a href="https://github.com/pnpm/action-setup/commit/ce859e384f8a1a0be70b423054e9fc15175c02a9"><code>ce859e3</code></a> refactor: replace <code>fs-extra</code> with Node.js built-in fs methods (<a href="https://redirect.github.com/pnpm/action-setup/issues/120">#120</a>)</li> <li><a href="https://github.com/pnpm/action-setup/commit/2ab6dce4f53589dada480b94c53cb05a06b04673"><code>2ab6dce</code></a> docs(README): fix link to LICENSE</li> <li><a href="https://github.com/pnpm/action-setup/commit/e280758d01dee817bb34e0eb1114fde6d3a9f1db"><code>e280758</code></a> docs(README): update dependency versions (<a href="https://redirect.github.com/pnpm/action-setup/issues/117">#117</a>)</li> <li><a href="https://github.com/pnpm/action-setup/commit/129abb77bf5884e578fcaf1f37628e41622cc371"><code>129abb7</code></a> Bump undici from 5.28.2 to 5.28.3 (<a href="https://redirect.github.com/pnpm/action-setup/issues/115">#115</a>)</li> <li><a href="https://github.com/pnpm/action-setup/commit/a3252b78c470c02df07e9d59298aecedc3ccdd6d"><code>a3252b7</code></a> docs(README): update version</li> <li><a href="https://github.com/pnpm/action-setup/commit/1ee9c9d01d7ec8c679f2f85de0ff31e8af2c9944"><code>1ee9c9d</code></a> feat!: node20 upgrade (<a href="https://redirect.github.com/pnpm/action-setup/issues/110">#110</a>)</li> <li><a href="https://github.com/pnpm/action-setup/commit/ebcfd6995dade4b0104ac774445cef8b3b4635b0"><code>ebcfd69</code></a> Bump actions/setup-node from 3 to 4 (<a href="https://redirect.github.com/pnpm/action-setup/issues/103">#103</a>)</li> <li><a href="https://github.com/pnpm/action-setup/commit/d2613e087f2e0aa841925861c5a5f7395d552177"><code>d2613e0</code></a> docs: update pnpm version in caching example (<a href="https://redirect.github.com/pnpm/action-setup/issues/94">#94</a>)</li> <li>Additional commits viewable in <a href="https://github.com/pnpm/action-setup/compare/v2...v4">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] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Francesco Novy <francesco.novy@sentry.io>
You can initialize the Node SDK like this: ```js import * as Node from '@sentry/node'; Sentry.initWithoutDefaultIntegrations({ dsn: '...', integrations: [...Sentry.getDefaultIntegrationsWithoutPerformance()] }); ``` Which can be used to tree shake all the otel performance instrumentation (except for http) away. Also adjusts the size limits to be the current values + ~15kb.
feat(redis): Support `mget` command in caching functionality
feat(redis): Support `setex` command in caching functionality
This PR ensures that if a replay is manually started (=no sample rates are defined at all, and a user later calls `start()` or `startBuffering()`, we do not back-port the `initialTimestamp` of the replay based on the event buffer. By default (for the first segment) we'll backport the `initialTimestamp` to the time of the first event in the event buffer, to ensure that e.g. the pageload browser metrics that may be emitted with an earlier timestamp all show up correctly. However, this may be unexpected if manually calling `startBuffering()` and seeing things for stuff that happened before. Now, we keep track of this and adjust the behavior accordingly. Fixes #11984 --------- Co-authored-by: Catherine Lee <55311782+c298lee@users.noreply.github.com>
…ktraces, values, or types (#12387)
…pp E2E test (#12368) This started out as updating the create-next-app test to not send to sentry anymore, but instead check payloads. However, while doing this, I noticed some inconsistencies, mostly that there was a weird `parent_span_id` in api route transactions/errors where there should be none. **EDIT** OK, another iteration on this! Turns out setting an invalid spanID on a span will make OTEL ignore all of this, including the trace ID, and instead will create a new trace ID for a new span, which is not what we want. So we can't use this... So instead, I now adjusted the already existing code to keep the incoming parentSpanId on the trace state. The major change I did is ensure we set this even if it is empty (it is set to an empty string then). This way, we can identify if this has been set, and if it has, use this as source of truth. And we can fall back to use the regular parentSpanId if this is not set (for whatever reason). **ORIGINAL** So I set out to figure out what was happening there, and the problem was that when continuing a virtual trace, we would construct a parent spanContext like this: ```js const spanContext: SpanContext = { traceId: propagationContext.traceId, spanId: propagationContext.parentSpanId || propagationContext.spanId, isRemote: true, traceFlags: propagationContext.sampled ? TraceFlags.SAMPLED : TraceFlags.NONE, traceState, }; ``` The problematic line is this: `spanId: propagationContext.parentSpanId || propagationContext.spanId,`. Since `spanId` is required on the SpanContext, we had to set it to something, but `propagationContext.parentSpanId` is by design often undefined. With this behavior, we always set this to the random span ID we have on the propagationContext, and picked this up downstream. this now became: ```js const spanContext: SpanContext = { traceId: propagationContext.traceId, spanId: propagationContext.parentSpanId || INVALID_SPANID, isRemote: true, traceFlags: propagationContext.sampled ? TraceFlags.SAMPLED : TraceFlags.NONE, traceState, }; ``` Plus a check further down: ```js const traceState = makeTraceState({ dsc, parentSpanId: spanId !== INVALID_SPANID ? spanId : undefined, sampled, }); ``` (Note, `INVALID_SPANID` is a constant exported from OTEL, which is basically `0000....`). I'll investigate in a follow up if it would make sense to always use this for the propagation context, instead of a random one today, plus ensuring that we always filter this out before we send, or something like this 🤔 Part of #11910
Adding a comment in `package.json` with `"//"` is safe, as npm reserved this for comments ([see here](https://groups.google.com/g/nodejs/c/NmL7jdeuw0M/m/yTqI05DRQrIJ)). --------- Co-authored-by: Francesco Novy <francesco.novy@sentry.io>
…ransaction by setting reportAllChanges to true (#12360) There's currently an issue where initial pageloads frequently do not capture LCP. This is because LCP is only reported when there is a user interaction on the page, or the user triggers a pagehide. Either of these events must happen within the initial pageload transaction boundary for the LCP value to be capture. Previously, in v7, we added custom code the the vendored LCP library to force report when closing the initial pageload transaction. This custom code was removed when we moved to v8. In this change, we are using the `reportAllChanges` option, so that any time a new LCP is detected, we add the LCP value to the initial pageload transaction, as long as the transaction has not closed yet. This solution is no worse than the previous solution in v7 because: - The risk of reporting an early LCP is the same because in either situation this is completely dependant on when the pageload transaction closes, which this PR does not change. - using `reportAllChanges`, we always go with the longest LCP recorded - We avoid introducing custom code to the vendored LCP library, and we use the intended `reportAllChanges`, so there's less risk of introducing a regression the next time we update the library. It's not a perfect solution, but I think it's reasonable to go with this until we come up with a better one (specifically to resolve the span/transaction boundary issue).
resolves #12242 (although there are still some follow ups) https://github.com/open-telemetry/opentelemetry-js/releases/tag/v1.25.0 I think this lockfile looks correct, but lmk if this feels off. resolves #12011 resolves #12059 resolves #12154 resolves #12237 resolves nodejs/import-in-the-middle#77 cc @mohd-akram
Lms24
approved these changes
Jun 6, 2024
4ffc6f5
to
61d4ca0
Compare
size-limit report 📦
|
mydea
approved these changes
Jun 7, 2024
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.
Let's get those OTEL fixes out!