Merge branch 'master' of github.com:getsentry/sentry-docs into smi/sveltekit/clean-up-manual-qs-instrumentation

Author: inventarSarah

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

@@ -76,8 +76,9 @@ There are some things we need to be careful about when running migrations.
 
 ### Testing
 
-Database migrations are risky operations that can lead to irreversible data loss or corruption. This is especially true for [data migrations](https://docs.djangoproject.com/en/4.0/topics/migrations/#data-migrations).
-For this reason, every migration should have a corresponding integration test.
+Note: Regular migrations that modify table structure don't need migration tests
+
+[Data migrations](https://docs.djangoproject.com/en/4.0/topics/migrations/#data-migrations) are particularly risky, since they operate on data and can lead to irreversible data loss or corruption. For this reason, every data migration should have a corresponding integration test.
 
 To test your migration, derive a test case from `TestMigrations` and add it to `tests/sentry/migrations`.
 For example:

develop-docs/sdk/expected-features/index.mdx

@@ -118,11 +118,13 @@ This functionality should be gated behind the `includeLocalVariables` option, wh
 
 ## Feature Flags
 
-An SDK may optionally support feature flag collection. Feature flags are collected on evaluation, stored on the scope, and submitted to Sentry on error obeying the schema specified in the <Link to="/sdk/data-model/event-payloads/contexts/#feature-flag-context">Feature Flag Context</Link> protocol documentation.
+An SDK may optionally track feature flag evaluations. Feature flags can be attached to error events or to span events.
 
-If an SDK supports feature flags it must expose a function `addFeatureFlag` which has similar behavior to the `set_tag` function. It must accept a key of type string and a value which is a union of string, boolean, integer, float, and structure. An SDK may hold up to 100 evaluations (similar to the breadcrumb implementation). Evaluations are ordered based on their evaluation time. Typically, an LRU cache is used to store feature flags. When the capacity of the cache is exceeded the oldest flag is dropped. Any (or multiple) data structure(s) may be chosen by the SDK to store feature flags as long as the evaluation order of the flags is maintained.
+When tracking feature flag evaluations on spans, we track the first 10 feature flags evaluated within the span's scope.  Evaluations are span attributes and follow the existing span attribute schema.
 
-Because flags are stored on the scope, when a scope forks the flags data structure must be cloned. Failure to clone the data structure appropriately will lead to flags leaking across thread boundaries and lead to unexpected results.
+When tracking on error feature flag evaluations, we record the 100 most recent, unique feature flag evaluations.  Evaluations are stored on the scope. When the scope forks a copy of the collected feature flag evaluations are given to the child scope.  Mutations to the child's copy of the feature flags object should not be propagated to the parent.  Flag evaluations within a scope are considered local to the scope and do not propagate.  Evaluations should be submitted to Sentry following the schema specified in the <Link to="/sdk/data-model/event-payloads/contexts/#feature-flag-context">Feature Flag Context</Link> protocol documentation.
+
+If an SDK supports feature flags it must expose a function `add_feature_flag` which has similar behavior to the `set_tag` function. It must accept a key of type string and a value which is a union of string, boolean, integer, float, and structure.
 
 ### Integrations
 

develop-docs/sdk/telemetry/logs.mdx

@@ -89,7 +89,7 @@ It consists of the following fields:
 
 : **Object, optional**. A dictionary of key-value pairs of arbitrary data attached to the log. Attributes must also declare the type of the value. The following types are supported: `string`, `boolean`, `integer`, `double`. In the future arrays will be supported (`string[]`, `boolean[]`, `integer[]`, `double[]`).
 
-Integers should be a 64-bit signed integer, while doubles should be a 64-bit floating point number. In the future we will support 64-bit unsigned integers.
+Integers should be a 64-bit signed integer, while doubles should be a 64-bit floating point number. For 64-bit unsigned integers, use the `string` type to avoid overflow issues. In the future we will support 64-bit unsigned integers.
 
 Example:
 

docs/concepts/key-terms/dsn-explainer.mdx

@@ -18,7 +18,7 @@ If an SDK is not initialized or if it is initialized with an empty DSN, the SDK
 
 DSNs are safe to keep public because they only allow submission of new events and related event data; they do not allow read access to any information.
 
-While there is a risk of abusing a DSN, where any user can send events to your organization with any information they want, this is a rare occurrence. Sentry provides controls to [block IPs](/platform-redirect/?next=/configuration/options/) and similar concerns. You can also rotate (and revoke) DSNs by navigating to **[Project] > Settings > Client Keys (DSN)**.
+While there is a risk of abusing a DSN, where any user can send events to your organization with any information they want, this is a rare occurrence. Sentry provides controls to [block IPs](/platform-redirect/?next=/configuration/options/) and similar concerns. You can also rotate (and revoke) DSNs by navigating to **[Project] > Settings > SDK Setup > Client Keys (DSN)**.
 
 If your application is shipped to client devices, if possible, we recommend having a way to configure the DSN dynamically. In an ideal scenario, you can "ship" a new DSN to your application without the customer downloading the latest version. We recognize that this may not always be practical, but we cannot offer further advice as this scenario is implementation specific.
 
@@ -28,7 +28,7 @@ If you're in the process of setting up a project, you can find your DSN in the i
 
 ![DSN in code snippet](./img/create-new-project-04.png)
 
-You can also find the DSN in your project settings by navigating to **[Project] > Settings > Client Keys (DSN)** in [sentry.io](https://sentry.io/).
+You can also find the DSN in your project settings by navigating to **[Project] > Settings > SDK Setup > Client Keys (DSN)** in [sentry.io](https://sentry.io/).
 
 ### The Parts of the Data Source Name (DSN)
 

docs/organization/getting-started/index.mdx

@@ -89,7 +89,7 @@ Automatic issue management is available only if your organization is on a Busine
 
 ## 4. Create Projects
 
-To start monitoring errors in your app with Sentry, you'll need to initialize the SDK with a DSN key. To obtain a key, add a new Sentry project by going to **Projects** and clicking "Create Project". Give the project a name and assign the responsible [team (or teams)](#2-set-up-teams). Then, retrieve the key in **[Project] > Settings > Client Keys (DSN)**.
+To start monitoring errors in your app with Sentry, you'll need to initialize the SDK with a DSN key. To obtain a key, add a new Sentry project by going to **Projects** and clicking "Create Project". Give the project a name and assign the responsible [team (or teams)](#2-set-up-teams). Then, retrieve the key in **[Project] > Settings > SDK Setup > Client Keys (DSN)**.
 
 ![Retrieve your project DSN key.](./img/project-dsn.png)
 

docs/platforms/android/index.mdx

@@ -31,7 +31,8 @@ Select which Sentry features you'd like to install in addition to Error Monitori
     'error-monitoring',
     'performance',
     'profiling',
-    'session-replay'
+    'session-replay',
+    'logs'
   ]}
 />
 
@@ -128,6 +129,10 @@ Configuration is done via the application `AndroidManifest.xml`. Here's an examp
   <!-- Enable profiling on app start -->
   <meta-data android:name="io.sentry.traces.profiling.start-on-app-start" android:value="true" />
   <!-- ___PRODUCT_OPTION_END___ profiling -->
+  <!-- ___PRODUCT_OPTION_START___ logs -->
+  <!-- Enable logs to be sent to Sentry -->
+  <meta-data android:name="io.sentry.logs.enabled" android:value="true" />
+  <!-- ___PRODUCT_OPTION_END___ logs -->
   <!-- ___PRODUCT_OPTION_START___ session-replay -->
   <!-- Record session replays for 100% of errors and 10% of sessions -->
   <meta-data android:name="io.sentry.session-replay.on-error-sample-rate" android:value="1.0" />

docs/platforms/dart/common/feature-flags/index.mdx

@@ -0,0 +1,27 @@
+---
+title: Set Up Feature Flags
+sidebar_order: 7000
+description: With Feature Flags, Sentry tracks feature flag evaluations in your application, keeps an audit log of feature flag changes, and reports any suspicious updates that may have caused an error.
+---
+
+<PlatformContent includePath="feature-flags/prerelease-alert" />
+
+## Prerequisites
+
+- [Sentry SDK](/platforms/dart/#configure) version `9.0.0`.
+
+## Enable Evaluation Tracking
+
+If you use a third-party SDK to evaluate feature flags, you can enable Sentry to track those evaluations. Integrations are provider specific, and documentation for supported SDKs is listed below:
+
+- [Firebase Remote Config](/platforms/dart/configuration/integrations/firebase-remote-config/)
+
+### Manual Usage
+
+Call `Sentry.addFeatureFlag` to track feature flag evaluations:
+
+```dart
+Sentry.addFeatureFlag("feature_flag_a", true);
+```
+
+Calling this function multiple times with the same flag name will override the previous value.

docs/platforms/dart/common/integrations/firebase-remote-config.mdx

@@ -0,0 +1,9 @@
+---
+title: Firebase Remote Config
+description: "Learn more about the Sentry Firebase Remote Config integration for the Dart SDK."
+sidebar_order: 50
+redirect_from:
+  - /platforms/dart/guides/firebase-remote-config/
+---
+
+<Include name="dart-integrations/firebase-remote-config.mdx" />

docs/platforms/dart/common/metrics/index.mdx

@@ -4,6 +4,53 @@ sidebar_order: 8000
 description: "Migrate between versions of Sentry's SDK for Dart."
 ---
 
+## Migrating from `sentry` `8.x` to `sentry` `9.x`
+
+#### Dart version
+
+The required minimium Dart version is now `3.5.0`. 
+This change allows us to use safer APIs and better support for features such as WASM compilation.
+
+#### API Removals and Renames
+
+- `LoadImagesListIntegration` has been renamed to `LoadNativeDebugImagesIntegration`.
+- The `enableTracing` option has been removed. Use `options.traceSampleRate` or `options.tracesSampler` instead.
+- `BeforeSendTransactionCallback` now has a `Hint` parameter.
+- Usage of `dart:html` has been removed in favor of `package:web`. The SDK is now packaged with the `package:web` dependency for better interoperability with web APIs.
+- The `segment` field from `SentryUser` has been removed.
+- The old user feedback API has been removed and replaced by `Sentry.captureFeedback`.
+
+#### Logging
+
+The default log level is now `warning` when `debug = true`. 
+This can be adjusted by setting `options.diagnosticLevel = SentryLevel.info` in `Sentry.init`.
+
+#### SDK Data Classes
+
+SDK data classes are now mutable which makes it easier to manipulate them. 
+For backwards-compatibility, `copyWith` and `clone` can still be used but are officially deprecated.
+
+```dart
+// old
+options.beforeSend = (event, hint) {
+  event = event.copyWith(release: 'my-release')
+  return event
+}
+
+// new
+options.beforeSend = (event, hint) {
+  event.release = 'my-release'
+  return event
+}
+```
+
+#### Response Body Handling
+
+Due to PII concerns, response bodies will no longer be added to Sentry events by the SDK automatically. 
+Responses are now attached to the `Hint` object, which can be read in `beforeSend`/`beforeSendTransaction` callbacks via `hint.response` so you can manually attach the response to your event.
+Response bodies with a size greater than 0.15MB are not added to the hint object.
+Currently as of version `9.0.0`, only the `dio` integration is supported.
+
 ## Migrating From `sentry` `6.18.x` to `sentry` `7.0.0`
 
 API changes: