hybrid-cloud-outboxes
Guide for creating and maintaining outbox-based eventually consistent operations in Sentry. Most commonly used for cross-silo data replication, but applicable anywhere eventual consistency is needed — including single-silo deferred side effects, audit logging, and event fanout. Use when asked to "add outbox", "add outbox replication", "replicate model to control silo", "replicate model to cell", "add outbox category", "write outbox signal receiver", "debug stuck outboxes", "outbox not processing", "data not replicating", "test outbox", "migrate model to use outboxes", "backfill outbox data", "outbox coalescing", "ReplicatedCellModel", "ReplicatedControlModel", "OutboxCategory", "OutboxScope", or "outbox_runner". Covers model mixins, category registration, signal receivers, testing, backfill, and debugging workflows.
Install
Install this Claude and Codex skill with the command below. The command stays visible even when copy support is unavailable.
git clone https://github.com/getsentry/sentry /tmp/sentry && ln -s /tmp/sentry/.agents/skills/hybrid-cloud-outboxes ~/.claude/skills/hybrid-cloud-outboxesFrom README
Hybrid Cloud Outboxes 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 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: CellOutbox — written in a Cell silo, processed in the Cell silo to push data toward Control (via RPC calls in signal receivers).