Merge branch 'master' into antonis/expo-debug-source-maps

Author: antonis

develop-docs/development/database-migrations/index.mdx

@@ -5,7 +5,7 @@ sidebar_order: 30
 
 Django migrations are how we handle changes to the database in Sentry.
 
-Django migration official docs: [https://docs.djangoproject.com/en/2.2/topics/migrations/](https://docs.djangoproject.com/en/2.2/topics/migrations/) . These will cover most things you need to understand what a migration is doing.
+Django migration official docs: [https://docs.djangoproject.com/en/5.1/topics/migrations/](https://docs.djangoproject.com/en/5.1/topics/migrations/) . These will cover most things you need to understand what a migration is doing.
 
 ## Commands
 

develop-docs/development/environment/index.mdx

@@ -55,20 +55,6 @@ You can create other users with `sentry createuser`.
 
 Please refer to [Frontend Development Server](/frontend/development-server/) and [Backend Development Server](/backend/development-server/) for alternative ways to bring up the Sentry UI.
 
-### Enabling HTTPS
-
-You may wish to run the development server in HTTPS mode. This can be done by generating and installing local certificates.
-
-We will be using [mkcert](https://github.com/FiloSottile/mkcert) to create and install a locally-trusted, development certificate. The following will install `mkcert` and then create and install the local certificates.
-
-```shell
-brew install mkcert
-brew install nss # if you use Firefox
-yarn mkcert-localhost
-```
-
-Running `sentry devserver` will automatically use HTTPS when the certificates have been installed.
-
 ### Ingestion Pipeline (Relay) aka Sending Events to your Dev Environment
 
 <Link to="/services/relay/">Relay</Link> and the ingest workers are not started by default. Follow the instructions below to start them so you can send events to your dev environment Sentry instance:

docs/concepts/key-terms/tracing/distributed-tracing.mdx

@@ -13,7 +13,15 @@ description: "Learn how to turn off Watchdog Termination tracking"
 
 This integration tracks [watchdog terminations](https://developer.apple.com/documentation/xcode/addressing-watchdog-terminations) based on heuristics. This feature is available for iOS, tvOS, and Mac Catalyst, works only if the application was in the foreground, and doesn't track watchdog terminations for unit tests.
 
-When a typical unhandled error occurs, the Apple SDK writes a report to disk with the current state of your application, with details like the stack trace, tags, breadcrumbs, and so on, before the app terminates. When the watchdog terminates your app this happens without further notice, which means the SDK can't write a report to disk. A common reason the watchdog can terminate your app is an Out Of Memory problem. If the app is terminated because it hangs, we don't create a watchdog termination event, but instead an `AppHangs` event is created.
+When a typical unhandled error occurs, the Apple SDK writes a report to disk before the app terminates. It includes the current state of your application with details like the stack trace, tags, breadcrumbs, and so on.
+
+The watchdog terminates your app without notice, which means the SDK can't write a report to disk.
+A common reason for the watchdog to terminate your app is an Out Of Memory problem. 
+
+Note, that there are some security-related types of crashes where the OS immediately terminates the app. These are usually infrequent, and include stack buffer overflows or exceptions with a termination reason related to code signing. Third-party libraries like Sentry can't report these incidents. 
+
+Those types of crashes can sometimes be visible in the [Xcode Organizer](https://developer.apple.com/documentation/xcode/acquiring-crash-reports-and-diagnostic-logs), though.
+If the app is terminated because it hangs, we won't create a watchdog termination event. An `AppHangs` event will be created instead.
 
 As a result, in the Apple SDK, we track watchdog terminations during the app start based on heuristics, but getting the state of the app when a watchdog termination occurs is challenging. The SDK adds breadcrumbs to watchdog termination events by appending the breadcrumbs to an open file, which should have a marginal impact on your app's performance. Still, it skips adding some frequently changing context to avoid extra I/O, such as free memory, free storage, device orientation, charging status, battery level, etc.
 

docs/platforms/apple/common/configuration/watchdog-terminations.mdx

@@ -111,6 +111,8 @@ curl -X POST \
 For the full list of supported values, see [_Event Payloads_](https://develop.sentry.dev/sdk/event-payloads/) and linked
 documents.
 
+If your minidump's size exceeds the [limits](#size-limits) in the next section, you can compress it using `gzip`, `zstd`, `bzip2` or `xz` and refer the `upload_file_minidump` to the compressed file instead of the plain minidump.
+
 ## Size Limits
 
 Event ingestion imposes limits on the size and number of fields in multipart

docs/platforms/native/guides/minidumps/index.mdx

@@ -67,7 +67,8 @@ sentry_sdk.init(
     # same as above
     integrations=[
         AioHttpIntegration(
-            transaction_style="method_and_path_pattern",
+            transaction_style="...",  # type: str
+            failed_request_status_codes={...}  # type: collections.abc.Set[int]
         ),
     ],
 )
@@ -84,6 +85,21 @@ Configure the way Sentry names transactions:
 
 The default is `"handler_name"`.
 
+### `failed_request_status_codes`
+
+A `set` of integers that will determine when an `HTTPException` should be reported to Sentry. The `HTTPException` is reported to Sentry if its status code is contained in the `failed_request_status_codes` set.
+
+Examples of valid `failed_request_status_codes`:
+
+- `{500}` will only report `HTTPException` with status 500 (i.e. `HTTPInternalServerError`).
+- `{400, *range(500, 600)}` will report `HTTPException` with status 400 (i.e. `HTTPBadRequest`) as well as those in the 5xx range.
+- `set()` (the empty set) will not report any `HTTPException` to Sentry.
+
+The default is `{*range(500, 600)}`, meaning that any `HTTPException` with a status in the 5xx range is reported to Sentry.
+
+Regardless of how `failed_request_status_codes` is set, any exceptions raised by the handler, which are not of type `HTTPException` (or a subclass) are reported to Sentry. For example, if your request handler raises an unhandled `AttributeError`, the `AttributeError` gets reported to Sentry, even if you have set `failed_request_status_codes=set()`.
+
+
 ## Supported Versions
 
 - AIOHTTP: 3.5+

docs/platforms/python/integrations/aiohttp/index.mdx

@@ -81,12 +81,12 @@ sentry_sdk.init(
     integrations=[
         StarletteIntegration(
             transaction_style="endpoint",
-            failed_request_status_codes=[403, range(500, 599)],
+            failed_request_status_codes={403, *range(500, 599)},
             http_methods_to_capture=("GET",),
         ),
         FastApiIntegration(
             transaction_style="endpoint",
-            failed_request_status_codes=[403, range(500, 599)],
+            failed_request_status_codes={403, *range(500, 599)},
             http_methods_to_capture=("GET",),
         ),
     ]
@@ -132,16 +132,16 @@ You can pass the following keyword arguments to `StarletteIntegration()` and `Fa
 
 - `failed_request_status_codes`:
 
-  A list of integers or containers (objects that allow membership checks via `in`)
-  of integers that will determine which status codes should be reported to Sentry.
+  A `set` of integers that will determine which status codes should be reported to Sentry.
 
   Examples of valid `failed_request_status_codes`:
 
-  - `[500]` will only send events on HTTP 500.
-  - `[400, range(500, 599)]` will send events on HTTP 400 as well as the 500-599 range.
-  - `[500, 503]` will send events on HTTP 500 and 503.
+  - `{500}` will only send events on HTTP 500.
+  - `{400, *range(500, 600)}` will send events on HTTP 400 as well as the 5xx range.
+  - `{500, 503}` will send events on HTTP 500 and 503.
+  - `set()` (the empty set) will not send events for any HTTP status code.
 
-  The default is `[range(500, 599)]`.
+  The default is `{*range(500, 600)}`, meaning that all 5xx status codes are reported to Sentry.
 
 - `http_methods_to_capture`:
 

docs/platforms/python/integrations/fastapi/index.mdx

@@ -59,7 +59,7 @@ sentry_sdk.init(
     integrations=[
         StarletteIntegration(
             transaction_style="endpoint",
-            failed_request_status_codes=[403, range(500, 599)],
+            failed_request_status_codes={403, *range(500, 599)},
             middleware_spans=False,
             http_methods_to_capture=("GET",),
         )
@@ -89,16 +89,16 @@ You can pass the following keyword arguments to `StarletteIntegration()`:
 
 - `failed_request_status_codes`:
 
-  A list of integers or containers (objects that allow membership checks via `in`)
-  of integers that will determine which status codes should be reported to Sentry.
+  A `set` of integers that will determine which status codes should be reported to Sentry.
 
   Examples of valid `failed_request_status_codes`:
 
-  - `[500]` will only send events on HTTP 500.
-  - `[400, range(500, 599)]` will send events on HTTP 400 as well as the 500-599 range.
-  - `[500, 503]` will send events on HTTP 500 and 503.
+  - `{500}` will only send events on HTTP 500.
+  - `{400, *range(500, 600)}` will send events on HTTP 400 as well as the 5xx range.
+  - `{500, 503}` will send events on HTTP 500 and 503.
+  - `set()` (the empty set) will not send events for any HTTP status code.
 
-  The default is `[range(500, 599)]`.
+  The default is `{*range(500, 600)}`, meaning that all 5xx status codes are reported to Sentry.
 
 - `middleware_spans`:
 

docs/platforms/python/integrations/starlette/index.mdx

@@ -43,7 +43,7 @@ module.exports = withSentryConfig(config, { annotateReactComponents: true });
 const { getSentryExpoConfig } = require("@sentry/react-native/metro");
 
 // const config = getDefaultConfig(__dirname);
-const config = getSentryExpoConfig(config, { annotateReactComponents: true });
+const config = getSentryExpoConfig(__dirname, { annotateReactComponents: true });
 ```
 
 ## How It Works

docs/platforms/react-native/integrations/component-names.mdx

@@ -34,7 +34,7 @@ module.exports = withSentryConfig(config);
 const { getSentryExpoConfig } = require("@sentry/react-native/metro");
 
 // const config = getDefaultConfig(__dirname);
-const config = getSentryExpoConfig(config, {});
+const config = getSentryExpoConfig(__dirname);
 ```
 
 ### Wrap Your Custom Serializer