getsentry · constantinius · Mar 20, 2026 · Mar 16, 2026 · Mar 16, 2026 · Mar 16, 2026
diff --git a/develop-docs/backend/application-domains/tasks/index.mdx b/develop-docs/backend/application-domains/tasks/index.mdx
@@ -270,6 +270,50 @@ This registers the task as both:
 - `integrations_tasks:sentry.widgets.tasks.do_work_v2` (new)
 - `issues_tasks:sentry.widgets.tasks.do_work` (old)
 
+## External Tasks
+
+An application can create tasks for another application to execute through the usage of
+**external namespaces**:
+
+```python
+from sentry.taskworker.app import app
+
+# Create an external namespace
+launchpad_tasks = app.create_external_namespace(
+  application="launchpad",
+  name="default"
+)
+```
+
+With an external namespace you can register and spawn **external tasks**.
+
+```python
+@launchpad_tasks.register(name="launchpad.task.name")
+def run_process(org_id: int, project_id: int, payload: bytes) -> None:
+    pass
+
+
+# Schedule the task
+run_process.delay(org_id=1, project_id=123, payload=blob)
+```
+
+Like local tasks, external tasks can typecheck their parameters and support all
+of the retry, deadline and idempotency features tasks provide. When an external
+task is produced, the producing application's task router will be used to
+resolve which topic external task activations are sent to. The task router will
+receive an application prefixed namespace name eg. `launchpad:default`.
+
+External tasks have a few restrictions:
+
+1. They cannot be called synchronously. Eg. `external_task_func(org_id)` will
+   fail with an exception as external tasks do not have an implementation in the
+   producing application.
+2. The `name` assigned to the external task **must** be the same as the task
+   name registered in the application  that will execute the task.
+3. External tasks must be mocked within a testing context manager. Within
+   a testing context manager, tasks become synchronous, and raise exceptions.
+
+
 ## Testing Tasks
 
 Tasks can be tested with a few different approaches. The first is with the

diff --git a/develop-docs/engineering-practices/ai-assisted-development.mdx b/develop-docs/engineering-practices/ai-assisted-development.mdx
@@ -96,10 +96,10 @@ Connect your AI assistant to the services your team already uses. These are the
 
 | Tool | What it gives you |
 | ---- | ----------------- |
-| [Sentry MCP](https://docs.sentry.io/product/sentry-mcp/) | Query errors, search issues, analyze traces, and get root cause analysis directly from your editor. |
+| [Sentry MCP](https://docs.sentry.io/ai/mcp/) | Query errors, search issues, analyze traces, and get Autofix (root cause analysis and code fixes) directly from your editor. |
 | [Linear MCP](https://github.com/jerhadf/linear-mcp-server) | Create, search, and update Linear issues without leaving your session. |
 | [Notion MCP](https://github.com/makenotion/notion-mcp-server) | Search and read Notion pages. Useful for pulling in specs, RFCs, and team docs as context. |
-| [Slack MCP](https://github.com/nicholasgriffintn/slack-mcp-server) | Read Slack threads and channels. Paste a bug report thread and say "fix." |
+| [Slack MCP](https://docs.slack.dev/ai/slack-mcp-server/) | Read Slack threads and channels. Paste a bug report thread and say "fix." |
 
 #### CLIs
 

diff --git a/develop-docs/engineering-practices/commit-messages.mdx b/develop-docs/engineering-practices/commit-messages.mdx
@@ -16,7 +16,7 @@ sidebar_order: 10
 
 ### Merge vs Rebase
 
-Sentry uses a rebase workflow. That means that every commit on its own should be a clear, functional, and stable change. This means that when you’re building a new feature, you should try to pare it down into functional steps, and when that’s not reasonable, the end patch should be a single commit. This is counter to having a Pull Request which may include “fix [unmerged] behavior”. Those commits should be squashed, and the final patch when landed should be rebased.
+Sentry uses a rebase workflow. That means that every commit on its own should be a clear, functional, and stable change. This means that when you’re building a new feature, you should try to parse it down into functional steps, and when that’s not reasonable, the end patch should be a single commit. This is counter to having a Pull Request which may include “fix [unmerged] behavior”. Those commits should be squashed, and the final patch when landed should be rebased.
 
 Remember: each commit should follow the commit message format and be stable (green build).
 

diff --git a/develop-docs/sdk/foundations/trace-propagation/index.mdx b/develop-docs/sdk/foundations/trace-propagation/index.mdx
@@ -128,23 +128,46 @@ This option replaces the non-standardized `tracingOrigins` option which was prev
 
 <SpecSection id="strict-trace-continuation" status="stable" since="1.3.0">
 
-### strictTraceContinuation
+### Strict Trace Continuation
 
-This **MUST** be a boolean value. Default is `false`. This option controls trace continuation from unknown 3rd party services that happen to be instrumented by a Sentry SDK.
+The `strictTraceContinuation` option controls whether to continue a trace when **either the incoming trace or the receiving SDK has an organization ID, but not both**. This scenario typically would happen if the incoming trace originates from a third-party service instrumented with Sentry.
 
-If the SDK is able to parse an org ID from the configured DSN, it **MUST** be propagated as a baggage entry with the key `sentry-org_id`. Given a DSN of `https://1234@o1.ingest.us.sentry.io/1`, the org ID is `1`, based on `o1`.
+#### Required Configuration Options
 
-Additionally, the SDK **MUST** be configurable with an optional `orgId: <org-id>` setting that takes precedence over the parsed value from the DSN. This option **SHOULD** be set when running a self-hosted version of Sentry or if a non-standard Sentry DSN is used, such as when using a local Relay.
+SDKs **MUST** support the following configuration options:
 
-On incoming traces, the SDK **MUST** compare the `sentry-org_id` baggage value against its own parsed value from the DSN or org setting. Only if both match, the trace is continued. If there is no match, neither the trace ID, the parent sampling decision nor the baggage **SHOULD** be taken into account. The SDK **SHOULD** behave like it is the head of trace in this case.
+- `strictTraceContinuation`: **MUST** be a boolean value. Default is `false`.
+- `orgId`: optional override of the organization ID [parsed from the DSN](https://develop.sentry.dev/sdk/foundations/transport/authentication/#parsing-the-dsn).
+  - SDK documentation for the `orgId` option **SHOULD** recommend setting `orgId` for self-hosted Sentry and local Relay setups.
 
-This behavior can be disabled by setting `strictTraceContinuation: false` in the SDK init call. Initially, SDKs **MUST** introduce this option with a default value of `false`. Once the majority of SDKs have introduced this option, the default value will change to `true` (in a major version bump), making it opt-out.
+<Alert level="info">
 
-Regardless of `strictTraceContinuation` being set to `true` or `false`, if the SDK is either configured with an `org` or was able to parse the value from the DSN, incoming traces containing an `org` value in the baggage that does not match the one from the receiving SDK, the trace is not continued.
+Once most SDKs support the `strictTraceContinuation` option, we intend to migrate the default value to `true`. As this change is breaking, it will be part of a major release.
+
+</Alert>
+
+#### The SDK's Organization ID
+
+The SDK **MUST** determine its organization ID as follows:
+- If `orgId` is present, the SDK's organization ID is the value passed to `orgId`.
+- Otherwise, the SDK's organization ID is the organization ID [in the DSN](https://develop.sentry.dev/sdk/foundations/transport/authentication/#parsing-the-dsn).
+- If `orgId` is absent and the DSN cannot be parsed, then the organization ID is missing.
+
+If the SDK has an organization ID, the SDK **MUST** propagate the organization ID in baggage as `sentry-org_id`.
+
+#### Continuing Traces
+
+On incoming traces, the SDK **MUST** compare the incoming `sentry-org_id` with its own organization ID, as defined above.
+
+- If both values are present and differ, the SDK **MUST NOT** continue the trace, regardless of `strictTraceContinuation`.
+- If exactly one value is present, the SDK **MUST NOT** continue when `strictTraceContinuation` is `true`, and **SHOULD** continue when it is `false`.
+- If both values are present and equal, or both are absent, the SDK **SHOULD** continue the trace.
+
+When the SDK does not continue a trace, the incoming trace ID, parent sampling decision, and incoming baggage **SHOULD** be ignored. In this case, the SDK **SHOULD** behave as the head of a trace.
 
 #### Examples
 
-| Baggage `sentry-org` | SDK `org` | `strictTraceContinuation` | Result |
+| Baggage `sentry-org_id` | SDK organization ID | `strictTraceContinuation` | Result |
 | --- | --- | :---: | --- |
 | 1 | 1 | false | continue trace |
 | none | 1 | false | continue trace |

diff --git a/develop-docs/sdk/getting-started/ai-tools/code-review/index.mdx b/develop-docs/sdk/getting-started/ai-tools/code-review/index.mdx
@@ -10,7 +10,7 @@ Sentry SDK repositories use AI code review tools to catch bugs, enforce standard
 
 Seer is Sentry's own AI platform. Its AI Code Review feature analyzes pull request diffs to predict errors, highlight potential bugs, and suggest improvements. It provides line-by-line comments, code summaries, risk assessments, and can even generate unit tests.
 
-https://docs.sentry.io/product/ai-in-sentry/seer/ai-code-review/
+https://docs.sentry.io/product/ai-in-sentry/seer/code-review/
 
 ### Activation
 

diff --git a/develop-docs/sdk/getting-started/playbooks/coordination/triaging.mdx b/develop-docs/sdk/getting-started/playbooks/coordination/triaging.mdx
@@ -27,7 +27,7 @@ Triage **SHOULD** prioritise acknowledgement and categorization over immediate f
 Triage **MAY** be bypassed if the issue was created by a team member.
 
 Related resources:
-- [Triaging SLA](/sdk/getting-started/standards/coordination-maintenance#triaging-sla) — 2 business day first response requirement
+- [Triaging SLA](/sdk/getting-started/standards/coordination-maintenance#issue-triage) — 2 business day first response requirement
 - [GitHub Saved Replies](/sdk/getting-started/templates/saved-replies) — team-approved response templates for common scenarios
 - [Handling an External Contributor PR](/sdk/getting-started/playbooks/development/handling-external-contributor-pr) — PR-specific triage workflow
 - [Handling a Regression](/sdk/getting-started/playbooks/development/handling-a-regression) — regression response process
@@ -50,7 +50,7 @@ Items **MAY** arrive through any of these channels. Social media is out of scope
 
 Response time expectations vary by channel:
 
-- **GitHub issues and PRs** — initial response **MUST** be within **2 business days** ([Triaging SLA](/sdk/getting-started/standards/coordination-maintenance#triaging-sla))
+- **GitHub issues and PRs** — initial response **MUST** be within **2 business days** ([Triaging SLA](/sdk/getting-started/standards/coordination-maintenance#issue-triage))
 - **Slack and Discord** — response **SHOULD** be within a **few hours** during business hours
 
 The response **MUST** acknowledge receipt and set expectations — a clarifying question, next steps, or a likely outcome. The initial response does not imply acceptance, prioritisation, or commitment to work.
@@ -79,11 +79,24 @@ Every item **MUST** exit the triage queue via exactly one of the following paths
 
 Prevent stagnation: escalate urgent issues and communicate unresolved issues promptly.
 
+#### 5. Respond to label states
+
+Labels are applied automatically to reflect where action is required:
+
+| Label | Meaning |
+| --- | --- |
+| **`Waiting for: Product Owner`** | The issue is waiting on the maintainer. This label carries a 2 business day SLA — the maintainer **MUST** respond within 2 business days each time this label is active. |
+| **`Waiting for: Community`** | The maintainer has responded and is awaiting a reply, reproduction, or confirmation from the reporter or community. |
+
+When an issue carries **`Waiting for: Product Owner`**, treat it as an active obligation in the triage queue — respond, investigate, or escalate within the SLA window. Labels reset automatically on each state transition.
+
+See also: [Waiting-for Labels](/sdk/getting-started/standards/coordination-maintenance#issue-triage)
+
 ---
 
 ## Referenced Standards
 
-- [Triaging SLA](/sdk/getting-started/standards/coordination-maintenance#triaging-sla) — 2 business day first response baseline and enforcement
+- [Triaging SLA](/sdk/getting-started/standards/coordination-maintenance#issue-triage) — 2 business day first response baseline and enforcement
 
 ---
 

diff --git a/develop-docs/sdk/getting-started/playbooks/development/adding-a-dependency.mdx b/develop-docs/sdk/getting-started/playbooks/development/adding-a-dependency.mdx
@@ -22,7 +22,7 @@ This playbook guides SDK maintainers through the process of adding a new depende
 
 Related resources:
 - [Dependency Management Standard](/sdk/getting-started/standards/code-quality#dependency-management) — dependency requirements and audit practices
-- [SDK Size and Performance Budgets](/sdk/getting-started/standards/code-quality#sdk-size-and-performance-budgets) — size and performance tracking requirements
+- [SDK Size and Performance Budgets](/sdk/getting-started/standards/code-quality#size-performance-budgets) — size and performance tracking requirements
 - [Security Practices](/sdk/getting-started/standards/code-quality#security-practices) — security requirements for dependencies
 
 ---
@@ -40,7 +40,7 @@ The issue **MUST** include documentation of the following:
 - Maintenance health (last release date, number of maintainers, open issue count)
 - Security posture (known vulnerabilities, audit history)
 - License compatibility
-- Size impact on the SDK (see [SDK size and performance budgets](/sdk/getting-started/standards/code-quality#sdk-size-and-performance-budgets))
+- Size impact on the SDK (see [SDK size and performance budgets](/sdk/getting-started/standards/code-quality#size-performance-budgets))
 
 #### 3. Get explicit approval
 
@@ -65,7 +65,7 @@ The PR reviewer **MUST** explicitly acknowledge the new dependency, not just app
 ## Referenced Standards
 
 - [Dependency Management](/sdk/getting-started/standards/code-quality#dependency-management) — requirements for adding and maintaining dependencies
-- [SDK Size and Performance Budgets](/sdk/getting-started/standards/code-quality#sdk-size-and-performance-budgets) — size and performance budget tracking
+- [SDK Size and Performance Budgets](/sdk/getting-started/standards/code-quality#size-performance-budgets) — size and performance budget tracking
 - [Security Practices](/sdk/getting-started/standards/code-quality#security-practices) — security requirements and vulnerability handling
 
 ---

diff --git a/develop-docs/sdk/getting-started/playbooks/development/handling-a-regression.mdx b/develop-docs/sdk/getting-started/playbooks/development/handling-a-regression.mdx
@@ -23,8 +23,8 @@ spec_changelog:
 This playbook guides SDK maintainers through handling regressions discovered after a release. It covers severity assessment, response options (patch release vs. rollback), communication protocols, and post-incident review. By following these steps, regressions will be resolved quickly with minimal user impact.
 
 Related resources:
-- [Post-release monitoring](/sdk/getting-started/standards/coordination-maintenance#post-release-monitoring) — how regressions are detected
-- [Rollback procedures](/sdk/getting-started/standards/coordination-maintenance#rollback-procedures) — emergency rollback process
+- [Post-release monitoring](/sdk/getting-started/standards/coordination-maintenance#releases) — how regressions are detected
+- [Rollback procedures](/sdk/getting-started/standards/coordination-maintenance#releases) — emergency rollback process
 - [Cutting a Release](/sdk/getting-started/playbooks/sdk-lifecycle/cutting-a-release) — standard release process (expedited for patches)
 
 ---
@@ -50,7 +50,7 @@ You **MUST** take one of the following actions:
 
 **Option B: Yank the release**
 - If a clean revert isn't possible, yank the bad release from the package registry
-- Follow the documented rollback procedure: [Rollback procedures](/sdk/getting-started/standards/coordination-maintenance#rollback-procedures)
+- Follow the documented rollback procedure: [Rollback procedures](/sdk/getting-started/standards/coordination-maintenance#releases)
 
 #### 3. Communicate
 
@@ -70,9 +70,9 @@ This helps identify gaps in testing, review processes, or monitoring that can be
 
 ## Referenced Standards
 
-- [Post-release monitoring](/sdk/getting-started/standards/coordination-maintenance#post-release-monitoring) — monitoring that detects regressions
-- [Rollback procedures](/sdk/getting-started/standards/coordination-maintenance#rollback-procedures) — emergency rollback process
-- [Release Gating Criteria](/sdk/getting-started/standards/review-ci#release-gating-criteria) — gates that may be expedited for critical patches
+- [Post-release monitoring](/sdk/getting-started/standards/coordination-maintenance#releases) — monitoring that detects regressions
+- [Rollback procedures](/sdk/getting-started/standards/coordination-maintenance#releases) — emergency rollback process
+- [Release Gating Criteria](/sdk/getting-started/standards/review-ci#release-gating) — gates that may be expedited for critical patches
 
 ---
 

diff --git a/.../sdk/getting-started/playbooks/development/handling-external-contributor-pr.mdx b/.../sdk/getting-started/playbooks/development/handling-external-contributor-pr.mdx
@@ -35,7 +35,7 @@ Related resources:
 
 #### 1. Triage within 2 business days
 
-([Review SLAs](/sdk/getting-started/standards/review-ci#review-slas)). Every external PR **REQUIRES** a timely, substantive response.
+([Review SLAs](/sdk/getting-started/standards/review-ci#code-review)). Every external PR **REQUIRES** a timely, substantive response.
 
 #### 2. Check for a linked issue
 
@@ -55,16 +55,16 @@ Review it using the standard process ([Reviewing a PR](/sdk/getting-started/play
 
 #### 6. When requesting changes
 
-You **MUST** be specific, use LOGAF prefixes ([Review feedback conventions](/sdk/getting-started/standards/review-ci#review-feedback-conventions)), and explain *why* — so the contributor (or their AI tool) can address the feedback effectively.
+You **MUST** be specific, use LOGAF prefixes ([Review feedback conventions](/sdk/getting-started/standards/review-ci#code-review)), and explain *why* — so the contributor (or their AI tool) can address the feedback effectively.
 
 #### 7. Closing fast is kind
 
 A 30-second close with a clear, respectful reason is better than a PR that sits open for weeks with no response. That respects everyone's time.
 
 ## Referenced Standards
 
-- [Review SLAs](/sdk/getting-started/standards/review-ci#review-slas) — timely response requirements
-- [Review feedback conventions](/sdk/getting-started/standards/review-ci#review-feedback-conventions) — LOGAF scale for feedback
+- [Review SLAs](/sdk/getting-started/standards/review-ci#code-review) — timely response requirements
+- [Review feedback conventions](/sdk/getting-started/standards/review-ci#code-review) — LOGAF scale for feedback
 - [PR description quality](/sdk/getting-started/standards/code-submission#pr-description-quality) — linked issue requirement
 
 ---

diff --git a/develop-docs/sdk/getting-started/playbooks/development/opening-a-pr.mdx b/develop-docs/sdk/getting-started/playbooks/development/opening-a-pr.mdx
@@ -75,7 +75,7 @@ When green, mark the PR as ready for review.
 
 #### 9. Assign 1–2 reviewers
 
-If the PR touches public API, dependencies, or security-sensitive areas, you **MUST** assign an @sdk-seniors reviewer ([Required reviewers](/sdk/getting-started/standards/review-ci#required-reviewers)).
+If the PR touches public API, dependencies, or security-sensitive areas, you **MUST** assign an @sdk-seniors reviewer ([Required reviewers](/sdk/getting-started/standards/review-ci#code-review)).
 
 ## Referenced Standards
 
@@ -87,8 +87,8 @@ If the PR touches public API, dependencies, or security-sensitive areas, you **M
 - [Changelog entry](/sdk/getting-started/standards/code-submission#changelog-entry) — user-facing change documentation
 - [One logical change per PR](/sdk/getting-started/standards/code-submission#one-logical-change-per-pr) — focused PR scope
 - [Documentation-with-code](/sdk/getting-started/standards/repository-docs#documentation-with-code) — docs PR requirements
-- [Required reviewers](/sdk/getting-started/standards/review-ci#required-reviewers) — @sdk-seniors review triggers
-- [Test requirements by change type](/sdk/getting-started/standards/code-quality#test-requirements-by-change-type) — test coverage requirements
+- [Required reviewers](/sdk/getting-started/standards/review-ci#code-review) — @sdk-seniors review triggers
+- [Test requirements by change type](/sdk/getting-started/standards/code-quality#testing) — test coverage requirements
 
 ---