Merge branch 'master' into kahest/android-sdk-overhead

Author: Karl Heinz Struggl

develop-docs/api-server/application-domains/database-migrations/index.mdx

@@ -287,7 +287,7 @@ Extra care is needed here if the table is referenced as a foreign key in other t
 
 - Make a pull request to remove all uses of the model in the codebase in a separate pull request. This mostly helps with code cleanliness. This should be merged ahead of the migration pull requests, but we don't need to worry about whether it is deployed first.
 - Make another pull request to:
-    - Remove any database level foreign key constraints from this table to other tables by setting `db_constraint=False` on the columns.
+    - Remove any database level foreign key constraints from this table to other tables by setting `db_constraint=False` on the columns. If it's a hybrid cloud foreign key, set `null=True` instead.
     - Remove the model and in the generated migration use `SafeDeleteModel(..., deletion_action=DeletionAction.MOVE_TO_PENDING)` to replace `DeleteModel(...)`. This only marks the state for the model as removed.
 - Deploy. It's important that all previous pull requests are in production before we remove the actual table.
 - Make a pull request that creates a new migration that has the same `SafeDeleteModel` operation as before, but set `deletion_action=DeletionAction.DELETE` instead. This deletes the actual table from Postgres.

develop-docs/engineering-practices/rust.mdx

@@ -50,26 +50,26 @@ During migration you may need normal functions which return futures, for their s
 
 ### Async Traits
 
-In **traits** you can not yet use `async fn` ([see this blog post](https://smallcultfollowing.com/babysteps/blog/2019/10/26/async-fn-in-traits-are-hard/)).
-In this case, functions should return `-> Pin<Box<dyn Future<Output = ...> + Send>>`:
+Support for async in **traits** has [landed in Rust](https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html)
+and should generally be preferred now.
 
 ```rust
-trait Database {
-    fn get_user(&self) -> Pin<Box<dyn Future<Output = User> + Send + '_>>;
+pub trait Database {
+    fn get_user(&self) -> impl Future<Output = User> + Send;
 }
 
-impl Database for MyDB {
-  fn get_user(&self) -> Pin<Box<dyn Future<Output = User> + Send + '_>> {
-    Box::pin(async {
-      // ...
-    })
-  }
+impl Database for MyDatabase {
+    async fn get_user(&self) -> User {
+        todo!()
+    }
 }
 ```
 
 Note that the returned future type is `Send`, to ensure that it can run on a multi-threaded runtime.
 
-This corresponds to what the [async-trait crate](https://crates.io/crates/async-trait) does.
+When you need dynamic dispatch or have to support Rust versions older than 1.75 consider using the
+[`async-trait`](https://docs.rs/async-trait/) crate.
+
 
 ### Avoid `.unwrap()`
 

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

@@ -261,14 +261,17 @@ To summarize:
 
 : _Optional_. An unprocessed description string obtained by the operating system. For some well-known runtimes, Sentry will attempt to parse `name` and `version` from this string, if they are not explicitly given.
 
-`distribution`
+`distribution_name`
 
-: _Optional_. An object that provides meta-data for Linux distributions. The values correspond to entries from the [`/etc/os-release`](https://www.freedesktop.org/software/systemd/man/latest/os-release.html#Options) configuration. Contains the following keys:
+: _Optional_. A stable name for each distribution. This maps to `ID` in [`/etc/os-release`](https://www.freedesktop.org/software/systemd/man/latest/os-release.html#ID=) (examples: `ubuntu`, `rhel`, `alpine`; a full list of tested identifiers is available in the [Native SDK repository](https://github.com/getsentry/sentry-native/blob/master/tests/fixtures/os_releases/distribution_names.txt))
 
+`distribution_version`
 
-- `name`: A stable name for each distribution. This maps to `ID` in `/etc/os-release` (examples: `ubuntu`, `rhel`, `alpine`; a full list of tested identifiers is available in the [Native SDK repository](https://github.com/getsentry/sentry-native/blob/feat/add_linux_distros_to_os_context/tests/fixtures/os_releases/distribution_names.txt).
-- `version`: _Optional_. Typically identifies at least the major release version number. This maps to `VERSION_ID` in `/etc/os-release`. Distributions with rolling releases only, will not provide a version.
-- `pretty_name`: _Optional_. Typically provides the full name, full version, and release alias. This maps to `PRETTY_NAME` in `/etc/os-release` (examples: `Ubuntu 22.04.4 LTS`, `Raspian GNU/Linux 10 (buster)`).
+: _Optional_. Typically identifies at least the major release version number. This maps to `VERSION_ID` in [`/etc/os-release`](https://www.freedesktop.org/software/systemd/man/latest/os-release.html#VERSION_ID=). Distributions with rolling releases only, will not provide a version.
+
+`distribution_pretty_name`
+
+: _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
 
@@ -293,10 +296,9 @@ The OS Context for the 3 major OSs should look like this:
     "type": "os",
     "name": "Linux",
     "version": "6.1.82(99.168.amzn2023.x86_64)",
-    "distribution": {
-      "name": "amzn",
-      "version": "2023",
-      "pretty_name": "Amazon Linux 2023.4.20240401"
+    "distribution_name": "amzn",
+    "distribution_version": "2023",
+    "distribution_pretty_name": "Amazon Linux 2023.4.20240401"
     }
   }
 }
@@ -628,7 +630,7 @@ Additional information that allows Sentry to connect multiple transactions, span
 
 `span_id`
 
-: _Required_. The ID of the span.
+: _Required_. The ID of the span or transaction. For non-transaction events, and if performance monitoring is disabled, it may still be desired to attach events to a trace via a trace ID. In these cases, you still need to provide a span ID. This span ID can effectively be entirely random and doesn't need to relate to an actual span, however, it is recommended to consider using the same span ID for multiple events within the same unit-of-execution (e.g. a request). [See the TwP docs](/sdk/telemetry/traces/tracing-without-performance/#attaching-trace-data-to-events-and-envelopes) for more details.
 
 - Example: `"bb8f278130535c3c"`
 

develop-docs/sdk/processes/releases.mdx

@@ -84,7 +84,7 @@ Nice!
 
 This file is used to trigger the release from the GitHub UI.
 
-You'll notice it uses `secrets.GH_RELEASE_PAT` -- this should already be
+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!
 
 ```yaml
@@ -105,14 +105,20 @@ jobs:
     runs-on: ubuntu-latest
     name: "Release a new version"
     steps:
+      - name: Get auth token
+        id: token
+        uses: actions/create-github-app-token@5d869da34e18e7287c1daad50e0b8ea0f506ce69 # v1.11.0
+        with:
+          app-id: ${{ vars.SENTRY_RELEASE_BOT_CLIENT_ID }}
+          private-key: ${{ secrets.SENTRY_RELEASE_BOT_PRIVATE_KEY }}
       - uses: actions/checkout@v3
         with:
-          token: ${{ secrets.GH_RELEASE_PAT }}
+          token: ${{ steps.token.outputs.token }}
           fetch-depth: 0
       - name: Prepare release
         uses: getsentry/action-prepare-release@v1
         env:
-          GITHUB_TOKEN: ${{ secrets.GH_RELEASE_PAT }}
+          GITHUB_TOKEN: ${{ steps.token.outputs.token }}
         with:
           version: ${{ github.event.inputs.version }}
           force: ${{ github.event.inputs.force }}
@@ -132,11 +138,16 @@ Here's [an example PR] and the [follow-up to fix `fetch-depth`].
 Give the following teams access to your repository:
 
 - `engineering` -> `write`
-- `release-bot` -> `elevated bot`
 
 You can do this self-service via the settings page of your repository:
 `https://github.com/getsentry/REPONAME_HERE/settings/access`
 
+## Create Ruleset for the Repo
+
+Download and save the [default ruleset template](/json/Default_ruleset.json) as a JSON file.
+
+Visit the ruleset setting page of your repository: `https://github.com/getsentry/REPONAME_HERE/settings/rules`, click on the green **New ruleset** button, choose **Import a ruleset**, and select the JSON file you just downloaded. You can tweak the ruleset settings, but please don't remove the App in the Bypass List.
+
 ## Making Your First Release!
 
 Navigate to the actions tab of your repository, locate the release workflow,

develop-docs/self-hosted/troubleshooting.mdx

@@ -23,6 +23,25 @@ CSRF_TRUSTED_ORIGINS = ["https://sentry.example.com", "http://10.100.10.10", "ht
 
 See [Django's documentation on CSRF](https://docs.djangoproject.com/en/4.2/ref/settings/#std-setting-CSRF_TRUSTED_ORIGINS) for further detail.
 
+### `sentry-data` volume not being cleaned up
+
+You may see the `sentry-data` taking too much disk space. You can clean it manually (or putting the cleanup cronjob in place).
+
+Find the Docker mountpoint for the volume by executing:
+```bash
+docker volume inspect sentry-data
+
+# Or if you prefer to do it directly (assuming you have `jq` on your system):
+docker volume inspect sentry-data | jq -r .[0].Mountpoint
+```
+
+Then run the following command to remove the contents of the volume for the last 30 days (change the `30` to whatever you want, it's in days):
+```bash
+# `/var/lib/docker/volumes/sentry-data/_data` refers to the mountpoint of the volume
+# from the output of the previous command. Change it if it's different.
+find /var/lib/docker/volumes/sentry-data/_data -type f -mtime +30 -delete
+```
+
 ## Kafka
 
 One of the most likely things to cause issues is Kafka. The most commonly reported error is

docs/concepts/key-terms/sample-rates.mdx

@@ -0,0 +1,47 @@
+---
+title: Sample Rates
+sidebar_order: 11
+description: Learn how to manage the amount of data you send and are billed for in Sentry by adjusting the sample rates of various Sentry products including Traces and Session Replays.
+---
+
+## Overview
+
+### What Is a Sample Rate?
+
+Adding Sentry to your app gives you a lot of valuable information about errors and performance you wouldn't otherwise get. And lots of information is good -- as long as it's the right information, at a reasonable volume. You can use sample rates to capture only a specified percentage of events like errors and traces.
+
+
+### Why Not Capture All Events?
+
+We recommend sampling your transactions for two reasons:
+
+1. Capturing a single trace involves minimal overhead, but capturing traces for every page load or API request may add an undesirable load to your system.
+
+1. Enabling sampling allows you to better manage the number of events sent to Sentry, so you can tailor your volume to your organization's needs and budget.
+
+Choose a sampling rate that balances data accuracy with performance and storage concerns. You should aim to collect enough data to get meaningful insights without overloading resources. If unsure, start with a low rate and gradually increase it as you understand your traffic patterns better.
+
+## Sampling Rate Options
+
+<Note>
+Some of the options below aren't available in every SDK; check out our platform-specific docs for more info.
+</Note>
+
+### Error Events
+
+- **SampleRate** - Configures the sample rate for error events, in the range of 0.0 to 1.0. The default is 1.0, which means that 100% of error events will be sent. If set to 0.1, only 10% of error events will be sent. Events are picked randomly.
+
+### Tracing
+
+- **tracesSampleRate** - A number between 0 and 1, controlling the percentage chance a given transaction will be sent to Sentry. (0 represents 0% while 1 represents 100%.) Applies equally to all transactions created in the app. Either this or `tracesSampler` must be defined to enable tracing.
+
+- **tracesSampler** - A function responsible for determining the percentage chance a given transaction will be sent to Sentry. It will automatically be passed information about the transaction and the context in which it's being created, and must return a number between 0 (0% chance of being sent) and 1 (100% chance of being sent). Can also be used for filtering transactions, by returning 0 for those that are unwanted. Either this or `tracesSampleRate` must be defined to enable tracing.
+
+Learn more about [tracing](/product/tracing/) in Sentry.
+### Session Replay
+
+- **replaysSessionSampleRate** - The sample rate for replays that begin recording immediately and last the entirety of the user's session. 1.0 collects all replays, and 0 collects none.
+
+- **replaysOnErrorSampleRate** - The sample rate for replays that are recorded when an error happens. This type of replay will record up to a minute of events prior to the error and continue recording until the session ends. 1.0 captures all sessions with an error, and 0 captures none.
+
+Learn more about [session replay](/product/explore/session-replay/) in Sentry.

docs/concepts/search/searchable-properties/events.mdx

@@ -472,6 +472,18 @@ The independent kernel version string. This is typically the entire output of th
 
 - **Type:** string
 
+### `os.distribution_name`
+
+The Linux distribution name. This maps to `ID` in [`/etc/os-release/`](https://www.freedesktop.org/software/systemd/man/latest/os-release.html).
+
+- **Type:** string
+
+### `os.distribution_version`
+
+The Linux distribution version. This maps to `VERSION_ID` in  [`/etc/os-release/`](https://www.freedesktop.org/software/systemd/man/latest/os-release.html).
+
+- **Type:** string
+
 ### `percentile(field,level)`
 
 Returns results with an approximate percentile of the field to the level. The level can be between `0` and `1`. For example, if you wanted to find the 50th percentile of transaction durations, you would enter `percentile(transaction.duration, 0.5)`.

docs/concepts/search/searchable-properties/issues.mdx

@@ -292,6 +292,18 @@ The independent kernel version string. This is typically the entire output of th
 
 - **Type:** string
 
+### `os.distribution_name`
+
+The Linux distribution name. This maps to `ID` in [`/etc/os-release/`](https://www.freedesktop.org/software/systemd/man/latest/os-release.html).
+
+- **Type:** string
+
+### `os.distribution_version`
+
+The Linux distribution version. This maps to `VERSION_ID` in  [`/etc/os-release/`](https://www.freedesktop.org/software/systemd/man/latest/os-release.html).
+
+- **Type:** string
+
 ### `platform.name`
 
 Name of the platform

docs/organization/integrations/feature-flag/launchdarkly/img/ff-integration-ui.png

@@ -1,12 +1,44 @@
 ---
 title: LaunchDarkly
 sidebar_order: 1
-description: Learn about Sentry's LaunchDarkly integration. LaunchDarkly enables organizations to use Sentry errors as a metric in their LaunchDarkly experiments.
+description: Learn about Sentry's LaunchDarkly integrations.
 ---
 
+## Evaluation Tracking
+
+Sentry can track flag evaluations as they happen within your application.  Flag evaluations will appear in the "Feature Flag" section of Issue Details page as a table, with "suspect" flag predictions highlighted in yellow. Learn more about how to interact with feature flag insights within the Sentry UI by reading the [Issue Details page documentation](/product/issues/issue-details/#feature-flags).
+
+### Set Up Evaluation Tracking
+
+To set up evaluation tracking visit one of our supported languages pages:
+* [JavaScript](/platforms/javascript/configuration/integrations/launchdarkly/)
+* [Python](/platforms/python/integrations/launchdarkly/)
+
+## Change Tracking
+
+Sentry can track changes to feature flag definitions and report suspicious feature flag edits.
+
+### Set Up Change Tracking
+
+Enabling Change Tracking is a three step process. To get started visit the [feature-flags settings page](https://sentry.io/orgredirect/organizations/:orgslug/settings/feature-flags) in a new tab. Then follow the steps listed below.
+
+1. **Click the "Add New Provider" button.
+    - One webhook secret can be registered per provider type.
+2. **Register the webhook URL**.
+    - Copy the provided Sentry webhook URL and paste it into LaunchDarkly within their [webhook integration UI](https://app.launchdarkly.com/settings/integrations/webhooks/new).
+3. **Set the Signing Secret**.
+    - In the LaunchDarkly webhook UI check the box that says "Sign this webhook".
+    - Copy the signing secret in the revealed input box and paste it into the input box labeled "Secret" in Sentry.
+    - Save the secret by clicking "Save Secret" in the Sentry fly out.
+    - Save the webhook by clicking "Save Settings" in LaunchDarkly.
+
+Once saved Sentry will now accept and authenticate all inbound hooks to your organization's feature flag webhook endpoint.
+
+## Metrics Integration
+
 This integration is maintained and supported by the company that created it. For more details or questions, feel free to contact [email protected].
 
-## Install and Configure
+### Install and Configure
 
 <Note>