Merge branch 'master' into sentry-otel-exporter

Author: jaffrepaul

AGENTS.md

@@ -63,3 +63,12 @@ When writing requirements in `develop-docs/`:
      This document uses key words such as "MUST", "SHOULD", and "MAY" as defined in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) to indicate requirement levels.
    </Alert>
    ```
+
+## Plan Mode
+
+- Make the plan extremely concise. Sacrifice grammar for the sake of concision.
+- At the end of each plan, give me a list of unresolved questions to answer, if any.
+
+## Pull Request generation 
+
+Use .github/PULL_REQUEST_TEMPLATE.md and add Co-Authored-By: Claude

develop-docs/sdk/processes/releases.mdx

@@ -85,7 +85,9 @@ Nice!
 This file is used to trigger the release from the GitHub UI.
 
 You'll notice it uses `vars.SENTRY_RELEASE_BOT_CLIENT_ID` and `secrets.SENTRY_RELEASE_BOT_PRIVATE_KEY` -- these should be
-available to your repository automatically!
+available to your repository automatically! These are needed because
+[GitHub prevents `GITHUB_TOKEN` from triggering downstream workflows](https://docs.github.com/en/actions/reference/events-that-trigger-workflows),
+which is required for creating publish request issues in `getsentry/publish`.
 
 ```yaml
 name: Release
@@ -95,7 +97,7 @@ on:
     inputs:
       version:
         description: Version to release
-        required: true
+        required: false
       force:
         description: Force a release even when there are release-blockers (optional)
         required: false
@@ -111,28 +113,29 @@ jobs:
         with:
           app-id: ${{ vars.SENTRY_RELEASE_BOT_CLIENT_ID }}
           private-key: ${{ secrets.SENTRY_RELEASE_BOT_PRIVATE_KEY }}
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v6
         with:
           token: ${{ steps.token.outputs.token }}
           fetch-depth: 0
       - name: Prepare release
-        uses: getsentry/action-prepare-release@v1
+        uses: getsentry/craft@v2
         env:
           GITHUB_TOKEN: ${{ steps.token.outputs.token }}
         with:
           version: ${{ github.event.inputs.version }}
           force: ${{ github.event.inputs.force }}
 ```
 
+For full details on all available options including auto-versioning, changelog preview,
+and more, see [Craft's GitHub Actions documentation](https://craft.sentry.dev/github-actions/).
+If your repository is outside the `getsentry` organization, you can use the simpler
+[reusable workflow](https://craft.sentry.dev/github-actions/#option-1-reusable-workflow-recommended)
+which handles token management automatically via `secrets: inherit`.
+
 ### Commit + PR
 
 **Commit those three files and make a pull request.**
 
-Here's [an example PR] and the [follow-up to fix `fetch-depth`].
-
-[an example PR]: https://github.com/getsentry/uwsgi-dogstatsd-plugin/pull/2
-[follow-up to fix `fetch-depth`]: https://github.com/getsentry/uwsgi-dogstatsd-plugin/pull/3
-
 ## Setting Up Permissions
 
 Give the following teams access to your repository:
@@ -158,6 +161,37 @@ add a label to.
 
 [issue in `publish`]: https://github.com/getsentry/publish/issues
 
+## Calendar Versioning (CalVer)
+
+To enable calendar versioning for your SDK, add the following to your `.craft.yml`:
+
+```yaml
+versioning:
+  policy: calver
+  calver:
+    format: "%y.%-m" # e.g., 24.12 for December 2024
+    offset: 14 # Days to look back for date calculation (optional)
+```
+
+See the [Craft CalVer documentation](https://craft.sentry.dev/configuration/#calendar-versioning-calver) for more details.
+
+## Merge Target
+
+By default, all releases are merged to the default branch of your repository (usually `main`). To override this, pass the `merge_target` input in your release workflow:
+
+```yaml
+- name: Prepare release
+  uses: getsentry/craft@v2
+  env:
+    GITHUB_TOKEN: ${{ steps.token.outputs.token }}
+  with:
+    version: ${{ github.event.inputs.version }}
+    merge_target: ${{ github.event.inputs.merge_target }}
+```
+
+Make sure to also add a `merge_target` input to your workflow's `workflow_dispatch.inputs` block.
+The same input is available in the [reusable workflow](https://craft.sentry.dev/github-actions/#option-1-reusable-workflow-recommended) as well.
+
 ## Version name conventions
 
 To keep versioning consistent across SDKs, we generally follow [semantic versioning (semver)](https://semver.org/), with language- or platform-specific conventions around semver (if applicable).
@@ -227,7 +261,7 @@ You can opt your repo into using the config from a specific merge target branch
 
 ### 1. Release Preparation:
 
-Add `craft_config_from_merge_target: true` when calling `getsentry/action-prepare-release` in your repo's release workflow:
+Add `craft_config_from_merge_target: true` when calling `getsentry/craft` in your repo's release workflow:
 
 ```yml
 # ...
@@ -238,12 +272,14 @@ jobs:
     steps:
       # ...
       - name: Prepare release
-        uses: getsentry/action-prepare-release@v1
+        uses: getsentry/craft@v2
         with:
           # ...
           craft_config_from_merge_target: true
 ```
 
+This input is also available in the [reusable workflow](https://craft.sentry.dev/github-actions/#option-1-reusable-workflow-recommended).
+
 ### 2. Publish Configuration
 
 Add the branch(es) you want to take the config from to the `publish.yml` workflow in `getsentry/publish`:

develop-docs/sdk/telemetry/metrics.mdx

@@ -393,7 +393,7 @@ By default the SDK should attach the following attributes to a metric:
 
 #### User Attributes
 
-SDKs may optionally attach user information as attributes (guarded by `sendDefaultPii`):
+SDKs may optionally attach user information as attributes (guarded by `sendDefaultPii` [unless manually set by user](/sdk/expected-features/data-handling/#sensitive-data)):
 
 1. `user.id`: The user ID. Maps to `id` in the [User](/sdk/data-model/event-payloads/user/) payload.
 2. `user.name`: The username. Maps to `username` in the [User](/sdk/data-model/event-payloads/user/) payload.

develop-docs/self-hosted/index.mdx

@@ -41,7 +41,7 @@ We recommend using 32 GB RAM, but it works with 16 GB RAM + 16 GB swap as well.
 
 Depending on your traffic volume, you may want to increase your system specification to handle increased load. Although most of the times, this is not the case for self-hosted Sentry, since no matter how small or big the traffic is, you will most likely hover around the same used resources.
 
-If increasing the disk storage space isn't possible, you can migrate your storage to use external storage such as AWS S3 or Google Cloud Storage (GCS). Decreasing your `SENTRY_RETENTION_DAYS` environment variable to lower numbers will save some storage space from being full, at the cost of having shorter data retention period. See [Event Retention](/self-hosted/configuration#event-retention) section.
+If increasing the disk storage space isn't possible, you can migrate your storage to use external storage such as AWS S3 or Google Cloud Storage (GCS). Decreasing your `SENTRY_EVENT_RETENTION_DAYS` environment variable to lower numbers will save some storage space from being full, at the cost of having shorter data retention period. See [Event Retention](/self-hosted/configuration#event-retention) section.
 
 Below is a breakdown of self-hosted Sentry installation compatibility with various Linux distributions:
 * **Debian/Ubuntu-based** distros are preferred; most users succeed with them, and they're used on Sentry's dogfood instance.

docs/platforms/android/configuration/img/tombstone_stacktrace.png

@@ -0,0 +1,87 @@
+---
+title: Android Native Crash Reporting (Tombstones)
+sidebar_order: 2
+description: Learn how to configure Tombstone support.
+---
+
+The Tombstone Integration generates events for native crashes based on data ("tombstones") that Android attaches to [`ApplicationExitInfo.REASON_CRASH_NATIVE`](https://developer.android.com/reference/android/app/ApplicationExitInfo#REASON_CRASH_NATIVE) starting with [Android 12+](https://developer.android.com/reference/android/app/ApplicationExitInfo#getTraceInputStream()).
+
+This crash context is collected by the operating system during the app’s shutdown after a crash. Because part of the collection runs out of process, it can capture richer crash details than the [NDK integration](/platforms/android/configuration/using-ndk/) and also is safer.
+
+In particular, you will get:
+
+* stack-traces for each of the threads in your process (which on Android is often key to understanding crashes)
+* improved stack traces through Android Runtime stack frames
+* client-side symbolication of all system libraries (while still allowing for server-side symbolication of your binaries to keep app size small)
+* safer crash context collection reduces crashes during crash handling
+* potentially smaller artifacts since the Tombstone Integration is part of `android-core` (if you [don't need the NDK integration](/platforms/android/configuration/using-ndk/#using-the-sdk-without-the-ndk) as a fallback)
+
+Keep in mind that the Tombstone Integration is not a full replacement for the NDK integration:
+
+* it only works on devices running Android 12+
+* if you instrument your native code with the NDK integration already, then Tombstones will only improve native crash reports, you still need the NDK integration for capturing native context
+
+However, if you don't develop native code for your apps, but use packages that have native code and a significant portion of your users runs on Android 12+, then the Tombstone Integration can be a replacement.
+
+![Tombstone Thread Stack Trace](./img/tombstone_stacktrace.png)
+
+#### Enabling the Tombstone Integration
+
+The Tombstone Integration is disabled by default. You can enable the tombstone integration using:
+
+```xml {filename:AndroidManifest.xml}
+<application>
+    <meta-data android:name="io.sentry.tombstone.enable" android:value="true" />
+</application>
+```
+
+#### Merging Tombstone and NDK Crash Events
+
+It generally makes sense run the [NDK integration](/platforms/android/configuration/using-ndk/) (`io.sentry.ndk.enable`) and the Tombstone integration at the same time:
+
+* if you have users on devices < Android 12 (in which case the NDK integration will solely be reporting native crashes)
+* if you use functions of the Native SDK from your native code and want your collected context to be reflected in the crash reports
+
+The reports from both integrations will be merged on the client into a single report, which will later be enriched. This means that whenever the Android version allows it, you will get improved crash reporting from tombstones; otherwise, the SDK falls back to the best-effort implementation from the NDK integration. In both cases, the Native SDK context is preserved in the final report.
+
+#### Tombstone Mechanisms
+
+We introduced two new mechanisms to help identify the integration from which reports originate:
+
+* A report originating only from a tombstone will be called `Tombstone`
+* A report being a merged result from a tombstone and a Native SDK event will be called `TombstoneMerged`
+* A report originating solely from the NDK integration (Native SDK) will continue to be called `signalhandler`
+
+#### Symbolication
+
+As mentioned above, Android infrastructure will try to symbolicate as much as possible on the client side. This is particularly important for system and framework symbols, since they can differ considerably across devices. If symbols cannot be resolved on the client - for instance, for your supplied binaries - the [backend symbolication](/platforms/android/configuration/using-ndk/#symbolicate-stack-traces) process follows the same rules as with the NDK integration.
+
+#### Debug Images
+
+In contrast to NDK integration, Tombstones retrieve module memory mappings at the time of the crash and are thus always up-to-date. If you use the NDK integration as a fallback for older Android versions, you still need to clear the module cache when dynamically loading libraries after app initialization.
+
+#### Historical Tombstones
+
+By default, the SDK only reports and enriches the latest Tombstones. However, there's also a `setReportHistoricalTombstones` option available in `SentryOptions`, which enables the SDK to report all Tombstones from the [getHistoricalExitReasons](<https://developer.android.com/reference/android/app/ActivityManager?hl=en#getHistoricalProcessExitReasons(java.lang.String,%20int,%20int)>) list:
+
+```kotlin
+SentryAndroid.init(context) { options ->
+  options.isReportHistoricalTombstones = true
+}
+```
+
+```java
+SentryAndroid.init(context) { options ->
+  options.setReportHistoricalTombstones(true)
+}
+```
+
+This option is useful after upgrading to an SDK version that introduces the Tombstone integration, as it allows you to report any tombstones that occurred before the update.
+
+It can also make sense if you get recurring reports of native crashes early during app start, or if your app regularly runs and restarts during longer offline periods.
+
+Other than that, the SDK will always pick up the latest Tombstone from the historical exit reasons list on the next app restart, and there won’t be any historical Tombstones to report. Also keep in mind that historical Tombstones will receive only minimal updates, as the available data is likely out of sync.
+
+#### Interaction with other Options
+
+Similar to ANR, for Tombstone derived events the options `attachThreads` and `attachStacktrace` are currently without effect.

docs/platforms/android/configuration/tombstones.mdx

@@ -10,6 +10,12 @@ NDK integration is packed with the SDK. The package `sentry-android-ndk` works b
 
 You can [disable the NDK integration](#disable-ndk-integration), or use our Sentry Android SDK [without the NDK](#using-the-sdk-without-the-ndk).
 
+<Alert>
+
+Starting with Sentry Android SDK version 8.32.0 you can enable the [Tombstone Integration](/platforms/android/configuration/tombstones/) as a replacement or extension to the NDK integration.
+
+</Alert>
+
 ## Symbolicate Stack Traces
 
 To symbolicate the stack trace from native code, we need to have access to the debug symbols of your application.
@@ -123,7 +129,7 @@ sentry_clear_modulecache();
 ```
 
 ```kotlin
-// 1. Manually initialize the SDK, 
+// 1. Manually initialize the SDK,
 // in order to keep a reference to the SDK options
 var optionsRef: SentryAndroidOptions? = null
 SentryAndroid.init(this) { options ->

docs/platforms/android/configuration/using-ndk.mdx

@@ -298,12 +298,10 @@ Sentry.init(
     dist: "<dist>",
     // ___PRODUCT_OPTION_START___ logs
     // Logs requires @sentry/capacitor 2.0.0 or newer.
-    _experiments: {
-      enableLogs: true,
-      beforeSendLog: (log) => {
-        // Add custom filters to logs.
-        return log;
-      }
+    enableLogs: true,
+    beforeSendLog: (log) => {
+      // Add custom filters to logs.
+      return log;
     },
     // ___PRODUCT_OPTION_END___ logs
     integrations: [
@@ -361,8 +359,16 @@ const app = createApp(App)
 
 Sentry.init(
   {
-    app,
     dsn: "___PUBLIC_DSN___",
+        
+    // Vue specific settings.
+    siblingOptions: {
+      vueOptions: {
+        app: app,
+        attachErrorHandler: false,
+        attachProps: true,
+      },
+    },
 
     // Adds request headers and IP for users, for more info visit:
     // https://docs.sentry.io/platforms/javascript/guides/capacitor/configuration/options/#sendDefaultPii
@@ -374,12 +380,10 @@ Sentry.init(
     dist: "<dist>",
     // ___PRODUCT_OPTION_START___ logs
     // Logs requires @sentry/capacitor 2.0.0 or newer.
-    _experiments: {
-      enableLogs: true,
-      beforeSendLog: (log) => {
-        // Add custom filters to logs.
-        return log;
-      }
+    enableLogs: true,
+    beforeSendLog: (log) => {
+      // Add custom filters to logs.
+      return log;
     },
     // ___PRODUCT_OPTION_END___ logs
     integrations: [
@@ -436,7 +440,6 @@ import * as SentryNuxt from "@sentry/nuxt";
 Sentry.init(
   {
     dsn: "___PUBLIC_DSN___",
-    
     // Adds request headers and IP for users, for more info visit:
     // https://docs.sentry.io/platforms/javascript/guides/capacitor/configuration/options/#sendDefaultPii
     sendDefaultPii: true,
@@ -447,12 +450,10 @@ Sentry.init(
     dist: "<dist>",
     // ___PRODUCT_OPTION_START___ logs
     // Logs requires @sentry/capacitor 2.0.0 or newer.
-    _experiments: {
-      enableLogs: true,
-      beforeSendLog: (log) => {
-        // Add custom filters to logs.
-        return log;
-      }
+    enableLogs: true,
+    beforeSendLog: (log) => {
+      // Add custom filters to logs.
+      return log;
     },
     // ___PRODUCT_OPTION_END___ logs
     integrations: [