Merge remote-tracking branch 'origin/master' into ShannonA-python-tracing-docs-refresh

Author: Shannon Anahata

apps/changelog/package.json

@@ -25,7 +25,7 @@
     "@radix-ui/react-icons": "^1.3.2",
     "@radix-ui/react-toolbar": "^1.1.0",
     "@radix-ui/themes": "^3.1.3",
-    "@sentry/nextjs": "9.9.0",
+    "@sentry/nextjs": "9.10.1",
     "@spotlightjs/spotlight": "^2.1.1",
     "next": "15.2.3",
     "next-auth": "^4.24.5",
@@ -68,4 +68,4 @@
     "@types/react": "npm:[email protected]",
     "@types/react-dom": "npm:[email protected]"
   }
-}
+}

apps/changelog/sentry.client.config.ts renamed to apps/changelog/src/instrumentation-client.ts

@@ -1,7 +1,3 @@
-// This file configures the initialization of Sentry on the client.
-// The config you add here will be used whenever a users loads a page in their browser.
-// https://docs.sentry.io/platforms/javascript/guides/nextjs/
-
 import * as SentryCore from '@sentry/core';
 import * as Sentry from '@sentry/nextjs';
 import * as Spotlight from '@spotlightjs/spotlight';

develop-docs/backend/application-domains/database-migrations/index.mdx

@@ -134,9 +134,9 @@ This is complicated due to our deploy process. When we deploy, we run migrations
 
 To avoid this, follow these steps:
 
-- Make a PR to remove all uses of the column in the codebase in a separate PR. This mostly helps with code cleanliness. This should be merged ahead of the migration prs, but we don't need to worry about whether it is deployed first.
+- First, if the column is either not nullable, or doesn't have a `db_default` set, then make a PR to make it nullable via `null=True`.
+- Then, remove all uses of the column in the codebase in a separate PR; this mostly helps with code cleanliness. This should be merged ahead of the next migration PRs, but we don't need to worry about whether it is deployed first.
 - Make another PR that:
-    - Checks if the column is either not nullable, or doesn't have a `db_default` set. If either of these is true, then make it nullable via `null=True`.
     - If the column is a foreign key, remove the database level foreign key constraint it by setting `db_constraint=False`.
     - Remove the column and in the generated migration use `SafeRemoveField(..., deletion_action=DeletionAction.MOVE_TO_PENDING)` to replace `RemoveField(...)`. This only marks the state for the column as removed.
     - Combine these migrations together to save making multiple deploys

develop-docs/development-infrastructure/continuous-integration.mdx

@@ -32,7 +32,7 @@ You might also be interested in <Link to="/development/environment/#troubleshoot
 
 **Problem:**
 
-When pushing your build to staging and you it fails the `Ensure test image` step on Travis.
+When pushing your build to staging and it fails the `Ensure test image` step on Travis.
 
 **Solution:**
 

develop-docs/sdk/data-model/event-payloads/contexts.mdx

@@ -8,7 +8,7 @@ related to the current user and the environment. For example, the device or
 application version. Its canonical name is `contexts`.
 
 The `contexts` type can be used to define arbitrary contextual data on the
-event. It accepts an object of key/value pairs. The key is the “alias” of the
+event. It accepts an object of key/value pairs. The key is the "alias" of the
 context and can be freely chosen. However, as per policy, it should match the
 type of the context unless there are two values for a type. You can omit `type`
 if the key name is the type.
@@ -273,7 +273,7 @@ To summarize:
 
 : _Optional_. Typically provides the full name, full version, and release alias. This maps to `PRETTY_NAME` in [`/etc/os-release`](https://www.freedesktop.org/software/systemd/man/latest/os-release.html#PRETTY_NAME=) (examples: `Ubuntu 22.04.4 LTS`, `Raspian GNU/Linux 10 (buster)`).
 
-### Example OS Context
+**Example OS Context**
 
 The OS Context for the 3 major OSs should look like this:
 
@@ -468,7 +468,7 @@ Examples: `"Apple Metal"` or `"Direct3D11"`
 
 : _Optional_. Are geometry shaders available on the device?
 
-### Example GPU Context
+**Example GPU Context**
 
 ```json
 {
@@ -496,7 +496,7 @@ The `type` and default key is `"state"`.
 
 : **Required**. Object with two keys: _Optional_ `type` for naming the state library (e.g.: Redux, MobX, Vuex) and **Required** `value` that holds the state object.
 
-### Example State Context
+**Example State Context**
 
 ```json
 {
@@ -598,7 +598,7 @@ The `type` and default key is `"cloud_resource"`.
 
 - Example: `t4g.medium`
 
-### Example Cloud Resource Context
+**Example Cloud Resource Context**
 
 The following example illustrates the contexts part of the <Link to="/sdk/data-model/event-payloads/">event payload</Link> and omits other attributes for simplicity.
 
@@ -720,7 +720,7 @@ The `route` currently supports the following predefined fields if it's a map:
 
 If the route is set to a string (e.g. `"route": "foo"`), it will be normalized into a map (e.g. `"route": {"name": "foo"}`) server-side.
 
-### Example Trace Context
+**Example Trace Context**
 
 ```json
 {
@@ -766,7 +766,7 @@ envelope endpoint.
 
 : **Required**. The replay_id associated with the event.
 
-### Example Replay Context
+**Example Replay Context**
 
 ```json
 {
@@ -792,7 +792,7 @@ This is mostly set on transactions in a web server environment where one transac
 
 - Example: `200`
 
-### Example Response Context
+**Example Response Context**
 
 ```json
 {
@@ -822,7 +822,7 @@ The required field is `package` which should contain the package or framework wh
 
 - Example: `true`
 
-### Example Response Context
+**Example Response Context**
 
 ```json
 {
@@ -852,7 +852,7 @@ The feature flag context contains information about the flags evaluated prior to
 - Example: `false`
 
 
-### Example Feature Flag Context
+**Example Feature Flag Context**
 
 ```json
 {

docs/contributing/pages/components.mdx

@@ -130,6 +130,12 @@ Render an expandable section to provide additional information to users on deman
   provide optional information that can help users be more successful.
 </Expandable>
 
+<Expandable title="Expandable with a code block">
+  ```js
+  const foo = 'bar';
+  ```
+</Expandable>
+
 ```markdown {tabTitle:Example}
 <Expandable title="Here's something worth noting">
   This is an expandable section in an `'info'` alert style.

docs/platforms/android/tracing/instrumentation/perf-v2.mdx

@@ -4,44 +4,41 @@ sidebar_order: 11
 description: "Learn how to get even more insights into Android app performance"
 ---
 
-<Alert>
+Performance V2 contains a set of features that enrich performance instrumentation. It tightly integrates with the [Mobile Vitals](/product/insights/mobile/mobile-vitals/) Insights module, enabling <PlatformLink to="/tracing/instrumentation/perf-v2/#app-start">App Start</PlatformLink> and <PlatformLink to="/tracing/instrumentation/perf-v2/#frames-delay">Frames Delay</PlatformLink> reporting.
 
-This feature is marked as _experimental_.
-Supported in Sentry's Android SDK version `7.4.0` and above.
-
-</Alert>
-
-Performance V2 is a set of features which enrich your existing instrumentation, giving you more insights into potential performance bottlenecks. These features tightly integrate with the [Mobile Vitals](/product/insights/mobile/mobile-vitals/) insights module.
+Since version 8 of the SDK, Performance V2 is generally available and enabled by default. In versions `7.4.0..<8.0.0`, this feature is available as _experimental_ and you need to opt in to use it:
 
 ### Enabling Performance V2
 
-```java {filename:MyApplication.java}
+```java {filename:MyApplication.java} {4}
 import io.sentry.android.core.SentryAndroid;
 
 SentryAndroid.init(this, options -> {
   options.setEnablePerformanceV2(true);
 });
 ```
 
-```kotlin {filename:MyApplication.kt}
+```kotlin {filename:MyApplication.kt} {4}
 import io.sentry.android.core.SentryAndroid
 
 SentryAndroid.init(this) { options ->
   options.enablePerformanceV2 = true
 }
 ```
 
-```xml {filename:AndroidManifest.xml}
+```xml {filename:AndroidManifest.xml} {3-5}
 <manifest>
     <application>
-        <meta-data android:name="io.sentry.performance-v2.enable" android:value="true" />
+        <meta-data
+          android:name="io.sentry.performance-v2.enable"
+          android:value="true" />
     </application>
 </manifest>
 ```
 
 ### App Start
 
-Besides enabling performance-v2, this feature requires the <PlatformLink to="/configuration/gradle/">Sentry Android Gradle Plugin</PlatformLink> (version `4.2.0` or above) to be applied to your app module.
+Besides enabling Performance V2, this feature requires the <PlatformLink to="/configuration/gradle/">Sentry Android Gradle Plugin</PlatformLink> (version `4.2.0` or above) to be applied to your app module.
 
 Once enabled, your App Start transaction will show a detailed span breakdown of various components:
 * `process.load`: The process initialization time

docs/platforms/android/troubleshooting/index.mdx

@@ -318,3 +318,5 @@ This problem is only relevant to these specific versions: `sentry-android-core`
 </Alert>
 
 Check [this issue](https://github.com/getsentry/sentry-android-gradle-plugin/issues/329) for more details.
+
+<PageGrid />

docs/platforms/android/troubleshooting/mixed-versions/index.mdx

@@ -0,0 +1,50 @@
+---
+title: Mixed Versions
+description: "Troubleshoot and resolve mixed Android SDK dependency versions."
+sidebar_order: 1000
+---
+
+Using multiple Android SDK dependencies with mixed versions is not supported as it is very likely to lead to a crash later on. For this reason we chose to crash the application on SDK init instead.
+
+## Multiple Dependencies With Mixed Versions
+
+The following snippet shows a mixed version conflict caused by using `sentry` with version `8.6.0` and `sentry-android` with version `8.7.0`. To fix the issue, set the same version for all dependencies or <PlatformLink to="/configuration/bill-of-materials/">use `sentry-bom`</PlatformLink>. This may also happen if you are using an internal library which has a different version defined.
+
+```groovy {tabTitle:Gradle}{filename:build.gradle}
+implementation('io.sentry:sentry:8.6.0')
+implementation('io.sentry:sentry-android:8.7.0')
+```
+```xml {tabTitle:Maven}{filename:pom.xml}
+<dependencyManagement>
+    <dependencies>
+        <dependency>
+            <groupId>io.sentry</groupId>
+            <artifactId>sentry</artifactId>
+            <version>8.6.0</version>
+        </dependency>
+        <dependency>
+            <groupId>io.sentry</groupId>
+            <artifactId>sentry-android</artifactId>
+            <version>8.7.0</version>
+        </dependency>
+    </dependencies>
+</dependencyManagement>
+```
+
+## Build Plugin And Explicit Dependency
+
+When using our Gradle or Maven plugin and manually defining additional Sentry Android SDK dependencies, it is also possible to end up with mixed versions. The following snippet shows the plugin being configured to use version `8.0.0` but there is an additional dependency that has been set to version `8.1.0`. To fix the issue,  set the same version or <PlatformLink to="/configuration/bill-of-materials/">use `sentry-bom`</PlatformLink>.
+
+```groovy {tabTitle:Gradle}{filename:build.gradle}
+plugins { id "io.sentry.android.gradle" version "5.3.0" }
+
+dependencies {
+	implementation 'io.sentry:sentry-okhttp:8.1.0'
+}
+
+sentry {
+	autoInstallation {
+		sentryVersion = "8.0.0"
+	}
+}
+```

docs/platforms/dotnet/common/configuration/options.mdx

@@ -49,9 +49,13 @@ Example scenarios where it should be explicitly set to true:
 
 Defaults to `false`, unless in Blazor WASM, MAUI, Unity, or Xamarin where the default is `true`.
 
-In server applications, when Global Mode is **disabled**, data stored in the scope is only available in the context of the particular request in which it is created.
+When Global Mode is **disabled** data stored in the scope is set on the current [ExecutionContext](https://learn.microsoft.com/en-us/dotnet/api/system.threading.executioncontext).
+In server applications data stored in the scope is only available in the context of the particular request in which it is created.
+Broadly, the ExecutionContext passes to child tasks and threads, but not to parent tasks and threads.
 
-For UI applications (like MAUI) when Global mode is **enabled**, a single scope stack is shared by the whole application.
+When Global Mode is **enabled**, a single scope stack is shared by the whole application.
+
+Since version 5.0.0 the transaction is always set on the current ExecutionContext, regardless of the Global Mode, so that spans from the UI don't get mixed up with transactions in background services.
 
 See the <PlatformLink to="/enriching-events/scopes/">Scopes and Hubs documentation</PlatformLink> for more information.