Merge branch 'master' into aspnetcore-6

Author: jamescrosswell

develop-docs/sdk/telemetry/logs.mdx

@@ -396,7 +396,7 @@ A new data category for logs has been added to Relay, `log_item`. Both the `log`
 
 ### Buffering
 
-Logs should be buffered before being sent. SDKs should keep a buffer of logs on the client (so you can have logs from multiple traces in the buffer) that flushes out based on some kind of condition. We recommend to use follow the [batch processor specification outlined](/sdk/telemetry/spans/batch-processor/) in the develop docs, but you should choose the approach that works best for your platform. When starting initial development on the SDK you can choose a simple approach to buffer like flushing logs if the buffer length exceeds 100 items, or if 5 seconds have passed.
+Logs should be buffered before being sent. SDKs should keep a buffer of logs on the client (so you can have logs from multiple traces in the buffer) that flushes out based on some kind of condition. We recommend to follow the [telemetry buffer specification outlined](/sdk/telemetry/telemetry-buffer/) in the develop docs, but you should choose the approach that works best for your platform. When starting initial development on the SDK you can choose a simple approach to buffer like flushing logs if the buffer length exceeds 100 items, or if 5 seconds have passed.
 
 SDKS should NOT release logging capabilities to users if a buffering implementation has not been added to their SDK when adding logging APIs.
 

develop-docs/sdk/telemetry/spans/batch-processor.mdx renamed to develop-docs/sdk/telemetry/telemetry-buffer.mdx

@@ -1,5 +1,7 @@
 ---
-title: Batch Processor
+title: Telemetry Buffer
+redirect_from:
+  - /sdk/telemetry/spans/batch-processor/
 ---
 
 <Alert level="warning">
@@ -10,6 +12,33 @@ title: Batch Processor
   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>
 
+The telemetry buffer sits between the client and the transport, temporarily buffering high-volume telemetry data such as spans and logs. The client SHOULD continue to pass low-volume telemetry data, such as events, directly to the transport. The telemetry buffer aims to efficiently batch data to reduce the number of outgoing HTTP requests and Sentry envelopes. Without buffering, each span or log would trigger its own request, quickly overwhelming our backends.
+
+```mermaid
+flowchart LR
+  Client[Client] -->|high-volume telemetry data| Buffer[TelemetryBuffer]
+  Buffer -->|buffered telemetry data| Transport[Transport]
+  Client -->|low-volume telemetry data| Transport
+```
+
+Because telemetry workloads and platform constraints vary widely, buffer requirements differ across environments. For example, backend SDKs need high throughput and backpressure management to handle large data volumes. Mobile SDKs have lower throughput and don't need to worry much about backpressure, but they do need to minimize data loss in the event of abnormal process termination. Browser and GDX SDKs also have different requirements.
+
+Therefore, we recommend implementing different types of telemetry buffers tailored to the platform's needs. As of Nov 5th, 2025, this page is under development, and we're currently refining the requirements for different platforms:
+
+* [BatchProcessor V0](#batchprocessor-v0): The BatchProcessor V0 outlines the initial requirements, primarily for logs, to avoid sending numerous HTTP requests. This section exists only as a placeholder until we fully spec out the other telemetry buffers.
+* [Backend Telemetry Buffer](#backend-telemetry-buffer): To be defined
+* [Mobile Telemetry Buffer](#mobile-telemetry-buffer): To be defined
+* [Browser Telemetry Buffer](#browser-telemetry-buffer): To be defined
+* [GDX Telemetry Buffer](#gdx-telemetry-buffer): To be defined
+
+# Common Requirements
+
+To be defined. Things like common API, client reports, etc.
+
+# BatchProcessor V0
+
+## Overview
+
 The BatchProcessor batches spans and logs into one envelope to reduce the number of HTTP requests. When an SDK implements span streaming or logs, it MUST use a BatchProcessor, which is similar to [OpenTelemetry's Batch Processor](https://github.com/open-telemetry/opentelemetry-collector/blob/main/processor/batchprocessor/README.md). The BatchProcessor holds logs and finished spans in memory and batches them together into envelopes. It uses a combination of time and size-based batching. When writing this, the BatchProcessor only handles spans and logs, but an SDK MAY use it for other telemetry data in the future.
 
 ## Specification
@@ -95,3 +124,19 @@ Scenario: 1 span added application crashes
   And loses the spans in the BatchProcessor
 
 ```
+
+# Backend Telemetry Buffer
+
+To be defined
+
+# Mobile Telemetry Buffer
+
+To be defined
+
+# Browser Telemetry Buffer
+
+To be defined
+
+# GDX Telemetry Buffer
+
+To be defined

docs/organization/early-adopter-features/index.mdx

@@ -23,3 +23,4 @@ Limitations:
 - [Span Summary](/product/insights/overview/transaction-summary/#span-summary)
 - [Dynamic Alerts](/product/alerts/create-alerts/metric-alert-config/#dynamic-alerts)
 - [New Trace Explorer With Span Metrics](/product/explore/new-trace-explorer/)
+- [Size Analysis](/product/size-analysis/)

docs/organization/integrations/issue-tracking/sentry-linear-agent/img/Linear-agent-help-options.png

@@ -9,7 +9,7 @@ og_image: /og-images/organization-integrations-issue-tracking-sentry-linear-agen
 
 <Alert title="Beta">
 
-**Sentry Agent for Linear** is in its beta phase. It is currently only available for US-based Sentry.io organizations. Changes to the UX and the agent functionality should be expected.
+**Sentry Agent for Linear** is in its beta phase. Changes to the UX and the agent functionality should be expected.
 
 </Alert>
 
@@ -24,7 +24,6 @@ This integration highly benefits from having [automation configured within Seer]
 Sentry owner, manager, or admin permissions are required to install this integration.
 
 Linear **won't** work with self-hosted Sentry.
-
 </Alert>
 
 Navigate to **Settings > Integrations > Linear (Sentry Agent)**, accept and install.
@@ -42,31 +41,87 @@ When the issue is delegated to the agent, the agent will automatically check for
 
 For comment based interactions, the integration accepts natural language. We attempt to parse the intent of the question and trigger the appropriate response. If it fails, we'll prompt the help command that will guide you through options.
 
-Currently the integration allows the user to run the following actions:
+Most actions are available via interactive buttons or natural language. Currently, the integration allows the user to run the following actions:
 
 - Issue Fix - Runs a Seer Issue Fix for the application.
 - Status - Updates the status of the issue.
 - Help - Displays the help command that will guide you through options.
+- Enable/Disable automatic Seer runs - Toggle whether Seer automatically runs (without confirmation) when issues are assigned in Linear.
+- Enable/Disable Seer PRs - Allow Seer to open pull requests automatically when fixes are ready.
+
+## Automation & Configuration
+
+When an issue is assigned to the Sentry Agent in Linear, the user will be prompted to link their account with Sentry. This creates the relationship between your Linear user and your Sentry user, and exposes the projects and Sentry resources the user has access to. 
+
+The OAuth consent screen shows what orgnaization is connecting to Linear as well as gives options that can be enabled to customize the Sentry Agent in Linear's behavior.
+
+<div style={{width: '50%'}}>
+
+![OAuth consent screen](./img/Linear-oauth-consent.png)
+
+</div>
+
+These options can also be managed within the agent interface after the account is linked through the `help` command and leveraging the select menu at the bottom.
+
+<div style={{width: '50%'}}>
+
+![Help command](./img/Linear-agent-help-options.png)
+
+</div>
+
+These options can also be enabled interactively during agent sessions. These options present themselves in the following ways: 
+
+- Via buttons after an issue is assigned:
+  - `Yes, run Seer RCA` runs Seer Root Cause Analysis (RCA) for the current issue
+  - `Yes, and run automatically in the future` enables automatic runs in the future for this workspace and starts Seer RCA for the current issue
+- Natural language controls:
+  - "enable automatic seer runs", "disable automatic seer runs"
+  - "enable Seer PRs", "disable Seer PRs"
 
 ## Assigning Sentry Agent to an Issue
 
 1. Navigate to an issue within Linear and select "Assign" from the dropdown menu in the right sidebar.
 
+   <div style={{width: '75%'}}>
+
    ![Select Sentry Agent for Linear](./img/Linear-Agent-Delegation.png)
 
+   </div>
+
 2. Select "Sentry" from the dropdown menu.
 
 3. The task will be moved into in-progress and the Sentry agent session will be created. If it's your first time using the Agent, you'll be prompted to authenticate. Use the "Link" button to link your Linear user to your Sentry user.
 
    ![Link Sentry Agent for Linear](./img/Linear-Linking-Auth.png)
 
-4. Once linked, you'll be asked if you want to run a Seer Issue Fix for the application. You can answer "Yes", or ask for "Help" to see more options.
+4. If auto-run is disabled, you'll see a prompt with buttons:
+
+   - `Yes, run Seer RCA`
+   - `Yes, and run automatically in the future`
+   <div style={{width: '65%'}}>
+   ![Enable automatic Seer runs](./img/Linear-run-or-run-always.png)
+   </div>
+
+5. If auto-run is enabled, the Agent will start Seer automatically and confirm it's running. Use "status" to check progress or view results. If an analysis already exists, the Agent will post the latest status or Sentry issue details.
+
+   <div style={{width: '65%'}}>
+
+   ![Seer RCA in Linear](./img/Linear-Sentry-RCA-2.png)
+
+   </div>
+
+   
+### Triage Rules 
+
+The Sentry Agent supports Linear's triage rules allowing you to tag issues with a custom label in Linear, and have it execute the Sentry Agent. Examples are below.
+
+#### Triage Configuration
 
-   ![Run Seer in Linear](./img/Linear-Help.png)
+![Triage Configuration](./img/Linear-triage-rule.png)
 
-5. If you answer "Yes", the Agent will run a Seer Issue Fix for the application. **Note**: You may need to prompt it for "Status" to see the results.
+#### Triage Action
 
-   ![RCA from Sentry Seer in Linear](./img/Linear-Sentry-RCA-2.png)
+![Triage Action](./img/Linear-triage-claim.png)
 
 ## Uninstalling the Integration
 

docs/organization/integrations/issue-tracking/sentry-linear-agent/img/Linear-oauth-consent.png

@@ -0,0 +1,38 @@
+---
+title: Size Analysis
+sidebar_title: Size Analysis
+sidebar_order: 5200
+description: Upload Android builds to Sentry for Size Analysis.
+---
+
+<Include name="size-analysis/ea" />
+
+[Size Analysis](/product/size-analysis) helps monitor your mobile app's size in pre-production to prevent unexpected size increases (regressions) from reaching users. Aside from being courteous to your users, a smaller app size helps boost installation and retention rates, especially for customers with limited storage or slower connections.
+
+## Getting Started
+
+**Accepted Formats**: AAB (preferred) | APK
+
+**Upload Mechanisms**: [Gradle](#uploading-with-gradle) | [Sentry CLI](#uploading-with-the-sentry-cli)
+
+### Uploading With Gradle
+
+<Include name="size-analysis/upload-gradle" />
+
+### Uploading With the Sentry CLI
+
+<Include name="size-analysis/upload-cli-android" />
+
+## Upload Metadata
+
+<Include name="size-analysis/upload-metadata" />
+
+### Build Configuration
+
+<Include name="size-analysis/build-configuration-android" />
+
+## What's Next?
+
+We strongly recommend integrating Size Analysis into your CI pipeline. Follow our guide on [getting set up in CI](/product/size-analysis/integrating-into-ci/).
+
+<PageGrid />