Merge branch 'master' into feat/batch-processor-abnormal-terminations

Author: philipphofmann

develop-docs/backend/application-domains/tasks/index.mdx

@@ -213,6 +213,63 @@ def deliver_issue_webhook(organization_id: int, group_id: int) -> None:
 
 If an idempotent task exceeds a processing deadline, it will *not* be retried.
 
+## Task Aliasing
+
+Task aliasing allows you to rename tasks or move them to different namespaces while maintaining backwards compatibility with existing task activations in Kafka. This is useful when refactoring task organization or renaming tasks without losing queued tasks. Task aliases inherit the same retry policy, processing deadline, and other configuration from the primary task definition.
+
+### Renaming a Task
+
+When renaming a task, use the `alias` parameter to specify the old task name:
+
+```python
+@instrumented_task(
+    name="sentry.widgets.tasks.do_work_v2",  # New task name
+    namespace=issues_tasks,
+    alias="sentry.widgets.tasks.do_work",    # Old task name
+)
+def do_work() -> None:
+    ...
+```
+
+New activations will be created using `name`. However, both task names will be registered and can process activations. Workers will handle tasks sent to either `do_work_v2` or `do_work` with the same function. 
+
+### Moving to a Different Namespace
+
+To move a task from one namespace to another, use the `alias_namespace` parameter:
+
+```python
+from sentry.taskworker.namespaces import issues_tasks, integrations_tasks
+
+@instrumented_task(
+    name="sentry.widgets.tasks.do_work",
+    namespace=integrations_tasks,  # New namespace
+    alias_namespace=issues_tasks,  # Old namespace
+)
+def do_work() -> None:
+    ...
+```
+
+The task will be registered in both `performance_tasks` and `issues_tasks` for the same task name `sentry.widgets.tasks.do_work`, allowing in-flight activations in the old namespace to process.
+
+### Renaming and Moving Together
+
+You can combine both `alias` and `alias_namespace` to rename a task and move it to a different namespace simultaneously:
+
+```python
+@instrumented_task(
+    name="sentry.widgets.tasks.do_work_v2",   # New name
+    namespace=integrations_tasks,             # New namespace
+    alias="sentry.widgets.tasks.do_work",     # Old name
+    alias_namespace=issues_tasks,             # Old namespace
+)
+def do_work() -> None:
+    ...
+```
+
+This registers the task as both:
+- `integrations_tasks:sentry.widgets.tasks.do_work_v2` (new)
+- `issues_tasks:sentry.widgets.tasks.do_work` (old)
+
 ## Testing Tasks
 
 Tasks can be tested with a few different approaches. The first is with the

develop-docs/development-infrastructure/backend-development-server.mdx

@@ -5,7 +5,7 @@ sidebar_order: 20
 
 (*see also: [Frontend Development Server](/frontend/development-server/)*)
 
-It's possible to run Sentry locally without ever having to build the frontend. It requires to circumvent `sentry devserver`. Instead, you configure:
+It's possible to run Sentry locally without ever having to build the frontend. It requires to circumvent the devserver. Instead, you configure:
 
 ```python
 # ~/.sentry/sentry.conf.py

develop-docs/development-infrastructure/environment/index.mdx

@@ -183,12 +183,6 @@ SENTRY_SILO_DEVSERVER=1 SENTRY_SILO_MODE=CONTROL getsentry django shell
 SENTRY_SILO_DEVSERVER=1 SENTRY_SILO_MODE=REGION SENTRY_REGION=us getsentry django shell
 ```
 
-## Troubleshooting
-
-The more up-to-date troubleshooting docs for the _internal_ development environment on MacOS are <Link to="https://www.notion.so/sentry/devenv-troubleshooting-1448b10e4b5d8080ba04f452e33de48d">here</Link>.
-
-You might also be interested in <Link to="/development/continuous-integration/#troubleshooting-ci">Troubleshooting CI</Link>.
-
 ---
 
 **Problem:** `DoesNotExist: Subscription matching query does not exist` during getsentry devserver

develop-docs/development-infrastructure/environment/troubleshooting.mdx

@@ -0,0 +1,3 @@
+# Troubleshooting Development Environment Issues
+
+The troubleshooting docs for the _internal_ development environment on MacOS are [here](https://www.notion.so/sentry/devenv-troubleshooting-1448b10e4b5d8080ba04f452e33de48d)

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

@@ -26,6 +26,10 @@ follow this rule of thumb:
 ordered from caller to callee, or oldest to youngest. The last frame is the
 one creating the exception.
 
+In cases where the event payload is oversized (for instance, for recursion / stackoverflow errors),
+some SDKs truncate the frames to make sure the event gets sent and is not dropped completely.
+The recommended way to truncate in this case is take 500 frames on both sides so that Relay can further truncate on both sides as it wishes.
+
 `registers`
 
 : _Optional_. A map of register names and their values. The values should

develop-docs/sdk/expected-features/data-handling.mdx

@@ -121,6 +121,7 @@ Fields in the event payload that allow user-specified or dynamic values are rest
 - Messages are limited to 8192 characters.
 - HTTP data (the body) is limited to 8kB. Always trim HTTP data before attaching it to the event.
 - Stack traces are limited to 50 frames. If more are sent, data will be removed from the middle of the stack.
+- Input messages in AI integrations recorded in the span attribute `gen_ai.request.messages` are limited to 20kB per span. Messages are trimmed and truncated if they exceed the limit, retaining the most recent messages.
 
 Additionally, size limits apply to all store requests for the total size of the request, event payload, and attachments. Sentry rejects all requests exceeding these limits. Please refer the following resources for the exact size limits:
 

develop-docs/sdk/platform-specifics/serverless-sdks/aws-lambda-development-environment.mdx

@@ -0,0 +1,207 @@
+---
+title: AWS Lambda Development Environment
+description: How to configure AWS Lambda to send data to a development Sentry instance.
+sidebar_order: 200
+---
+
+This guide will explain how you can setup a development environment to work on the [AWS Lambda Integration](https://docs.sentry.io/product/integrations/cloud-monitoring/aws-lambda/). The setup includes running a local instance of `sentry` and configuring AWS so that both environments work together.
+
+<Alert level="warning" title="IMPORTANT">
+
+**This guide is only if you want to send data from an AWS Lambda function to your local `sentry` instance.**
+
+When working on the Sentry AWS Lambda layer from one of the SDKs, the workflow is that you have your example Lambda function in a dev account on AWS and then deploy your local layer to the dev account and attach it to your example function. How do to this in Python is described in the [contribution guide](https://github.com/getsentry/sentry-python/blob/master/CONTRIBUTING.md#contributing-to-sentry-aws-lambda-layer) of the Python SDK.
+
+</Alert>
+
+## Configuration of AWS
+
+To emulate a Sentry integration with a project base on AWS Lambda functions you need:
+
+- One AWS account representing Sentry having an IAM and a S3 Bucket containing a JSON config file.
+- One AWS account representing the user that has a example Lambda function.
+
+### Detailed Configuration Steps
+
+For the **“Sentry Account”** in AWS we assume the AWS Account ID is `1111 1111 1111` in this guide. This account can be the shared official dev AWS account of Sentry, or you can create a personal one (credit card required for this)
+
+- Create an **IAM user** in the **“Sentry account”** that can create S3 buckets, and has permission to assume roles. The policy that can be directly attached to the IAM user looks like this:
+
+  {/* _TODO: check if we can restrict those permissions more_ */}
+
+  ```json
+  {
+    "Version": "2012-10-17",
+    "Statement": [
+      {
+        "Sid": "VisualEditor0",
+        "Effect": "Allow",
+        "Action": "sts:AssumeRole",
+        "Resource": "*"
+      }
+    ]
+  }
+  ```
+
+- Create an **S3 Bucket in “Sentry Account”** that is accessible by the public to host the CloudFormation configuration file. (more on this later). The S3 Bucket Policy should look like this (in this example “sentry-dev-cloudformation” is the name of the S3 bucket):
+
+  {/* _TODO: check if we can restrict those permissions more_ */}
+
+  ```json
+  {
+    "Version": "2012-10-17",
+    "Statement": [
+      {
+        "Sid": "Statement1",
+        "Effect": "Allow",
+        "Principal": "*",
+        "Action": "s3:*",
+        "Resource": [
+          "arn:aws:s3:::sentry-dev-cloudformation",
+          "arn:aws:s3:::sentry-dev-cloudformation/dev.json"
+        ]
+      }
+    ]
+  }
+  ```
+
+- Place a **CloudFormation configuration file** called `dev.json` in the S3 bucket of the “Sentry account”  mentioned above. The `dev.json` file is a pointer to a “Sentry account” user. The file must be readable by the customer.
+  The dev.json must look like this. You need to replace `arn:aws:iam::111111111111:user/sentry` with the ARN of your user:
+
+      {/* *TODO: check if we can restrict those permissions more.* */}
+
+      ```json
+      {
+        "Description": "This stack grants write access to your Lambda functions in order to add Sentry error and performance monitoring. After pressing create, wait for the stack to be created before copying your AWS account number and region into the Sentry installation modal.",
+        "Resources": {
+          "SentryRole": {
+            "Type": "AWS::IAM::Role",
+            "Properties": {
+              "AssumeRolePolicyDocument": {
+                "Version": "2012-10-17",
+                "Statement": [
+                  {
+                    "Effect": "Allow",
+                    "Principal": {
+                      "AWS": "arn:aws:iam::111111111111:user/sentry"
+                    },
+                    "Action": [
+                      "sts:AssumeRole"
+                    ],
+                    "Condition": {
+                      "StringEquals": {
+                        "sts:ExternalId": {
+                          "Ref": "ExternalId"
+                        }
+                      }
+                    }
+                  }
+                ]
+              },
+              "Path": "/",
+              "RoleName": "SentryRole",
+              "ManagedPolicyArns": [],
+              "Policies": [
+                {
+                  "PolicyName": "sentry-policy",
+                  "PolicyDocument": {
+                    "Version": "2012-10-17",
+                    "Statement": [
+                      {
+                        "Effect": "Allow",
+                        "Action": [
+                          "lambda:UpdateFunctionConfiguration",
+                          "lambda:ListFunctions",
+                          "lambda:ListLayerVersions",
+                          "lambda:GetFunction",
+                          "lambda:GetLayerVersion",
+                          "organizations:DescribeAccount"
+                        ],
+                        "Resource": "*"
+                      }
+                    ]
+                  }
+                }
+              ]
+            }
+          }
+        },
+        "Parameters": {
+          "ExternalId": {
+            "Description": "External ID for securing the role - Do not change",
+            "Type": "String"
+          }
+        }
+      }
+      ```
+
+      This CloudFormation config file basically gives the user in the “Sentry account” access to assume a role in the “User account” to augment the Lambda functions (add the Sentry Lambda Layer) to instrument them for sending errors/metrics to Sentry
+
+- Create one **AWS** account representing the user and where the Lambda functions of the user live. This account we will call the **User account”**.
+  The **“Sentry account”** and the **“User account”** can also be the same account.
+
+Ok, so now you have two AWS accounts and you have set up your CloudFormation config in a S3 bucket that is accessible to the world. Great!
+
+## Configuration of Local Sentry Instance
+
+You need just a default installation of `sentry` on your computer. Please install it following the [Development Environment Setup Guide](https://develop.sentry.dev/development-infrastructure/environment/).
+
+Now you have to tell your sentry installation what AWS account to use and where it can find the CloudFormation configuration.
+
+You can do this by adding the following parameter to your `~/.sentry/config.yml` file:
+
+```yaml
+aws-lambda.access-key-id: AKIXXXXXXXXXXXXXXXXX
+aws-lambda.secret-access-key: IuyXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX2Xoj
+aws-lambda.cloudformation-url: https://sentry-dev-cloudformation.s3.eu-central-1.amazonaws.com/dev.json
+aws-lambda.node.layer-version: "37"
+aws-lambda.python.layer-version: "142"
+```
+
+Explanation:
+
+- `aws-lambda.access-key-id` AWS access key id of the IAM user created in the “Sentry Account”.
+- `aws-lambda.secret-access-key`AWS secret access key of the IAM user created in the “Sentry Account”.
+- `aws-lambda.cloudformation-url` public accessible URL of the CloudFormation config file that lives in a S3 bucket in the “Sentry Account”.
+- `aws-lambda.node.layer-version` the version of the Lambda layer that should be used for Node Lambda functions. This version number can be found here: [https://github.com/getsentry/sentry-release-registry/tree/master/aws-lambda-layers](https://github.com/getsentry/sentry-release-registry/tree/master/aws-lambda-layers) (Hint: every region can have another version of the Layer installed.)
+- `aws-lambda.python.layer-version` same as above but for Python based Lambda functions.
+
+## Configuration of Ngrok
+
+With [Ngrok](https://ngrok.com/) you get an URL that points to your local computer. So everyone on the internet can talk to your Sentry installation on your computer.
+
+This is needed so your AWS Lambda function can send its errors/tracing to your local Sentry installation.
+
+Follow the instructions on the [Ngrok documentation](https://develop.sentry.dev/development/ngrok/) page to install ngrok.
+
+Now start Ngrok like the following:
+
+```bash
+ngrok http 8000
+```
+
+If ngrok starts it outputs the URL that your computer is now available at. Copy the HTTP URL (it should look something like `http://xxxx-xxx-xxx-x-xxx.ngrok.io`).
+
+If you follow the guide in the ngrok page linked above you will get access to the Sentry Ngrok account and you can create a subdomain that is custom and not always changing when you restart ngrok. This is highly recommended.
+
+You now have to tell your sentry installation its new URL by adding the following line to your `~/.sentry/config.yml` :
+
+```yaml
+system.url-prefix: "http://xxxx-xxx-xxx-x-xxx.ngrok.io"
+```
+
+Make sure to restart all the development environment, to make sure all services know about the new URL. (with `devservices down && devservices up`)
+
+## Start the Local Sentry Server
+
+If you now run your local Sentry with this command, it will have all the information it needs:
+
+```bash
+devservices serve
+```
+
+You are now ready for serverless integration development.
+
+## Add Sentry to Your Lambda Functions
+
+Log into your local sentry environment at your ngrok URL and follow the [AWS Lambda Guide](https://docs.sentry.io/product/integrations/cloud-monitoring/aws-lambda/) in our documentation to add Sentry instrumentation to your demo AWS Lambda function.

develop-docs/sdk/platform-specifics/serverless-sdks/aws-lambda.mdx

@@ -1,6 +1,6 @@
 ---
-title: AWS Lambda
-sidebar_order: 10
+title: AWS Lambda Primer
+sidebar_order: 100
 ---
 
 Lambda functions can be written in numerous programming languages (JavaScript,

develop-docs/sdk/platform-specifics/serverless-sdks/download-production-lambda-layer.mdx

@@ -0,0 +1,44 @@
+---
+title: How to Download Production Sentry Lambda Layer
+description: Instructions for downloading the Sentry AWS Lambda layer.
+sidebar_order: 300
+---
+
+You need to have the [AWS CLI](https://aws.amazon.com/cli/) installed and configured to have access to the production Sentry AWS account.
+
+Then you can get information about the Sentry Lambda layer with this command:
+```bash
+aws lambda get-layer-version --layer-name arn:aws:lambda:eu-central-1:943013980633:layer:SentryPythonServerlessSDK --version-number 142
+```
+Make sure you have the region (in the example `eu-central-1`) and the version number (in the example `142`) to the version of the layer you want to download. If you want to download the Javascript layer use `SentryNodeServerlessSDKvX` (replacing `X` with the version of the JS SDK is in the layer) instead of `SentryPythonServerlessSDK`.
+
+Output will be something like this:
+
+```bash
+{
+    "Content": {
+        "Location": "https://awslambda-eu-cent-1-layers.s3.eu-central-1.amazonaws.com/snapshots/943013980633/SentryPythonServerlessSDK-008d308b-4dc8-46c4-b7f2-48c31e187a85?versionId=xxx&X-Amz-Security-Token=xxx&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20260825T072152Z&X-Amz-SignedHeaders=host&X-Amz-Expires=600&X-Amz-Credential=xxx&X-Amz-Signature=xxx",
+        "CodeSha256": "L/xPQraARPazFPwChPLlzETN2emli4UIgabUOu34bZ4=",
+        "CodeSize": 9883188
+    },
+    "LayerArn": "arn:aws:lambda:eu-central-1:943013980633:layer:SentryPythonServerlessSDK",
+    "LayerVersionArn": "arn:aws:lambda:eu-central-1:943013980633:layer:SentryPythonServerlessSDK:35",
+    "Description": "",
+    "CreatedDate": "2026-08-16T11:15:45.768+0000",
+    "Version": 142,
+    "CompatibleRuntimes": [
+        "...",
+        "python3.13",
+        "python3.14"
+    ],
+    "LicenseInfo": "MIT"
+}
+```
+
+Then pick the `Location` and download the layer as zip file:
+
+```bash
+curl -o layer.zip https://awslambda-eu-cent-1-layers.s3.eu-central-1.amazonaws.com/snapshots/943013980633/SentryPythonServerlessSDK-008d308b-4dc8-46c4-b7f2-48c31e187a85?versionId=xxx&X-Amz-Security-Token=xxx&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20260825T072152Z&X-Amz-SignedHeaders=host&X-Amz-Expires=600&X-Amz-Credential=xxx&X-Amz-Signature=xxx
+```
+
+Now your layer is in `layer.zip`. Enjoy!

develop-docs/sdk/telemetry/logs.mdx

@@ -188,7 +188,7 @@ Sentry.logger.warn("User %s performed action %s", [userId, actionName], {
 });
 ```
 
-Aside from accepting attributes, these methods can be overloaded to accept severity number or other parameters if required for the language or platform.
+Aside from accepting attributes, these methods can be overloaded to accept severity number or other parameters if required for the language or platform. The Hub/Scope MUST offer the same methods as the static API `Sentry.logger.X`, which is useful for power users who want to use multiple Hubs/Scopes. The Client SHOULD only offer one generic method that accepts the log object and the Scope, such as `captureLog(log, scope)`.
 
 Beyond the specified methods, SDKs are free to add any extra helpers as they feel is necessary. For example, they could choose to add specialized decorators or helpers for string template creation.
 
@@ -255,6 +255,8 @@ In general log processing should follow this order:
 
 1. Capture log via [Public APIs](#logger-module) (e.g. `Sentry.logger.info`) or via [SDK integrations](#sdk-integrations).
 1. Check if logging is enabled as per `enableLogs`/`enable_logs` configuration - if not, skip the rest of the steps.
+1. Pass the log to Hub/Scope, which MUST offer the same methods as the static API `Sentry.logger.X`. This is useful for power users who want to use multiple Hubs/Scopes.
+1. Pass the log to the Client, via a generic method that accepts the log object and the `scope`, such as `captureLog(log, scope)`.
 1. Process captured log (attach attributes as per [default attributes](#default-attributes)).
 1. Run `beforeSendLog`/`before_send_log` to filter or modify the log.
 1. Add log to buffer/batch processor as detailed in [buffering](#buffering).