Merge branch 'master' into shellmayr/chore/remove-db-lvl-constraints-mark-for-delete-customdynamicsamplingrue

Author: shellmayr

.agents/skills/hybrid-cloud-outboxes/SKILL.md

@@ -18,11 +18,11 @@ description: >-
 
 Sentry uses a **transactional outbox pattern** for eventually consistent operations. When a model changes, an outbox row is written inside the same database transaction. After the transaction commits, the outbox is drained — firing a signal that triggers side effects such as RPC calls, tombstone propagation, or audit logging.
 
-The most common use case is **cross-silo data replication**: a model saved in the Region silo produces a `RegionOutbox` that, when processed, replicates data to the Control silo (or vice versa via `ControlOutbox`). But the pattern is general — outboxes work for any operation that should happen reliably after a transaction commits, even within a single silo.
+The most common use case is **cross-silo data replication**: a model saved in the Cell silo produces a `CellOutbox` that, when processed, replicates data to the Control silo (or vice versa via `ControlOutbox`). But the pattern is general — outboxes work for any operation that should happen reliably after a transaction commits, even within a single silo.
 
 There are two outbox types corresponding to the two directions of flow:
 
-- **`RegionOutbox`** — written in a Cell silo, processed in the Cell silo to push data toward Control (via RPC calls in signal receivers).
+- **`CellOutbox`** — written in a Cell silo, processed in the Cell silo to push data toward Control (via RPC calls in signal receivers).
 - **`ControlOutbox`** — written in the Control silo, processed in the Control silo to push data toward one or more Cell silos. Each `ControlOutbox` row targets a specific `cell_name`.
 
 ## Critical Constraints
@@ -66,7 +66,7 @@ There are two outbox types corresponding to the two directions of flow:
 
 | Data lives in... | Replicates toward... | Mixin                    | Outbox type     |
 | ---------------- | -------------------- | ------------------------ | --------------- |
-| Cell silo        | Control silo         | `ReplicatedCellModel`    | `RegionOutbox`  |
+| Cell silo        | Control silo         | `ReplicatedCellModel`    | `CellOutbox`    |
 | Control silo     | Cell silo(s)         | `ReplicatedControlModel` | `ControlOutbox` |
 
 ### 2.2 `ReplicatedCellModel` Template
@@ -148,7 +148,7 @@ class MyModel(ReplicatedCellModel):
 
 ### 2.3 `ReplicatedControlModel` Template
 
-Use this when a Control model needs to replicate data to Region silo(s). The key difference: Control outboxes fan out to one or more cells, so the model must declare which cells to target.
+Use this when a Control model needs to replicate data to Cell silo(s). The key difference: Control outboxes fan out to one or more cells, so the model must declare which cells to target.
 
 ```python
 from sentry.db.models import control_silo_model
@@ -360,7 +360,7 @@ def test_idempotent_replication(self):
 
 ### 7.3 Silo Test Decorators
 
-- Use **`@cell_silo_test`** for tests focused on `RegionOutbox` creation
+- Use **`@cell_silo_test`** for tests focused on `CellOutbox` creation
 - Use **`@control_silo_test`** for tests focused on `ControlOutbox` creation
 - Use **`@all_silo_test`** for end-to-end replication tests that exercise both silos
 - Only use **`TransactionTestCase`** for threading/concurrency tests (e.g., `threading.Barrier`), not for standard outbox drain tests

.agents/skills/hybrid-cloud-outboxes/references/backfill.md

@@ -110,7 +110,7 @@ Each batch (via `process_outbox_backfill_batch`):
 
 1. Calls `_chunk_processing_batch` to determine the ID range `(low, up)` for this batch
 2. For each instance in `model.objects.filter(id__gte=low, id__lte=up)`:
-   - Region models: `inst.outbox_for_update().save()` inside `outbox_context(flush=False)`
+   - Cell models: `inst.outbox_for_update().save()` inside `outbox_context(flush=False)`
    - Control models: saves all `inst.outboxes_for_update()` inside `outbox_context(flush=False)`
 3. If no more rows: sets cursor to `(0, replication_version + 1)` (marks complete)
 4. Otherwise: advances cursor to `(up + 1, version)`
@@ -141,7 +141,7 @@ options.get("outbox_replication.sentry_mymodel.replication_version")
 ### Check Outbox Queue Depth
 
 ```sql
--- Region outboxes for a specific category
+-- Cell outboxes for a specific category
 SELECT count(*) FROM sentry_regionoutbox
 WHERE category = <category_value>;
 

.agents/skills/hybrid-cloud-outboxes/references/debugging.md

@@ -45,7 +45,7 @@ When debugging stuck outboxes, you'll often need to generate SQL for a developer
 
 | Direction          | Model class     | Table name             |
 | ------------------ | --------------- | ---------------------- |
-| Cell -> Control    | `RegionOutbox`  | `sentry_regionoutbox`  |
+| Cell -> Control    | `CellOutbox`    | `sentry_regionoutbox`  |
 | Control -> Cell(s) | `ControlOutbox` | `sentry_controloutbox` |
 
 **How to determine direction**: Look at the model that changed.

.agents/skills/hybrid-cloud-rpc/references/service-template.md

@@ -7,7 +7,7 @@ from .model import *  # noqa
 from .service import *  # noqa
 ```
 
-## `model.py` (REGION silo example)
+## `model.py` (CELL silo example)
 
 ```python
 # Please do not use
@@ -125,7 +125,7 @@ def serialize_my_thing(obj: MyThing) -> RpcMyThing:
     )
 ```
 
-## `service.py` (REGION silo)
+## `service.py` (CELL silo)
 
 ```python
 # Please do not use
@@ -223,7 +223,7 @@ class MyMappingService(RpcService):
 my_mapping_service = MyMappingService.create_delegation()
 ```
 
-## `impl.py` (REGION silo example)
+## `impl.py` (CELL silo example)
 
 ```python
 from __future__ import annotations

.agents/skills/hybrid-cloud-test-gen/references/outbox-tests.md

@@ -12,7 +12,7 @@ import pytest
 
 from sentry.hybridcloud.models.outbox import (
     ControlOutbox,
-    RegionOutbox,
+    CellOutbox,
     outbox_context,
 )
 from sentry.hybridcloud.outbox.category import OutboxCategory, OutboxScope
@@ -181,7 +181,7 @@ class Test{Feature}OutboxProcessing(TestCase):
 - **`assume_test_silo_mode_of(Model)`** is preferred for checking a specific model's state cross-silo. Auto-detects the model's silo.
 - **`assume_test_silo_mode(SiloMode.X)`** for blocks accessing multiple models or non-model resources.
 - **Factory calls** (`self.create_organization()`, etc.) must NEVER be wrapped in `assume_test_silo_mode`. Factories handle silo mode internally.
-- **`@control_silo_test`** for tests focused on `ControlOutbox` records. **`@cell_silo_test`** for `RegionOutbox`.
+- **`@control_silo_test`** for tests focused on `ControlOutbox` records. **`@cell_silo_test`** for `CellOutbox`.
 - Only use **`TransactionTestCase`** for threading/concurrency tests (e.g., `threading.Barrier`), not for standard outbox drain tests.
 - Outbox drain fixtures can clear state between tests:
   ```python

.agents/skills/sentry-backend-bugs/references/missing-records.md

@@ -17,7 +17,7 @@ The most common sources of stale IDs:
 1. **Snuba/ClickHouse query results** -- Snuba stores issue IDs, project IDs, and group IDs that may be deleted from Postgres before Snuba data expires
 2. **Workflow engine references** -- Detectors, subscriptions, and alert rules reference objects deleted asynchronously
 3. **Integration state** -- SentryAppInstallation, ServiceHook, or ExternalActor deleted while alert rules still reference them
-4. **Cross-silo references** -- Region silo holds IDs that reference control silo objects (or vice versa) that may be deleted asynchronously
+4. **Cross-silo references** -- Cell silo holds IDs that reference control silo objects (or vice versa) that may be deleted asynchronously
 5. **Cached foreign keys** -- A ProjectKey cached in Redis still references a `project_id` for a deleted project
 6. **Monitor/cron references** -- Environment objects referenced by monitors that may be deleted
 
@@ -120,7 +120,7 @@ except Subscription.DoesNotExist:
 | Environment deleted while monitors reference it | High      | `Environment.objects.get(id=monitor.env_id)`    |
 | Integration uninstalled while rules active      | High      | Alert rules referencing deleted SentryApp       |
 | Cached FK target deleted                        | Medium    | `get_from_cache(id=fk_id)` after parent deleted |
-| Cross-silo object deleted asynchronously        | Medium    | Region silo references control silo object      |
+| Cross-silo object deleted asynchronously        | Medium    | Cell silo references control silo object        |
 
 ## Fix Patterns
 

.agents/skills/sentry-security/references/endpoint-patterns.md

@@ -174,7 +174,7 @@ projects = self.get_projects(
 | -------------- | ---------------------- | ------------------------------------ | ------------------------------------------- |
 | Org-scoped     | `OrganizationEndpoint` | `organization` in kwargs             | `OrganizationPermission` (org:read for GET) |
 | Project-scoped | `ProjectEndpoint`      | `organization` + `project` in kwargs | `ProjectPermission`                         |
-| Region silo    | `RegionSiloEndpoint`   | Nothing — must implement own auth    | None                                        |
+| Cell silo      | `CellSiloEndpoint`     | Nothing — must implement own auth    | None                                        |
 | Control silo   | `ControlSiloEndpoint`  | Nothing — must implement own auth    | None                                        |
 
-If an endpoint inherits `RegionSiloEndpoint` or `Endpoint` directly instead of `OrganizationEndpoint`/`ProjectEndpoint`, verify it has its own authorization logic.
+If an endpoint inherits `CellSiloEndpoint` or `Endpoint` directly instead of `OrganizationEndpoint`/`ProjectEndpoint`, verify it has its own authorization logic.