Distillation

Date: July 30, 2026

• 🔴 (16:25) User pushed back on the volume-drop mechanism: in their mental model, the flag should "only affect already processed (which gets event_accepted fired) events" — so the dramatic volume drop doesn't make sense to them. User's intuition is that already-in-nodestore events have already had their signal fired, so skipping them shouldn't lose signal volume
• 🟡 (16:25) Assistant clarified there are TWO filters in process_event that prevent event_accepted from firing: (1) dedup cache check at processors.py:117-131 — cache.get(deduplication_key) catches events processed within ~1 hour; (2) reprocess_only_events_not_in_nodestore flag check at processors.py:192-196 — catches events whose body is in nodestore. The flag is the SECOND filter, catching events that slip past dedup
• 🟡 (16:25) Assistant identified the dedup cache (processors.py:117-131) catches most "already-processed" events within ~1 hour via cache.get(deduplication_key). So on the MAIN ingest consumer, the reprocess flag's incremental impact should be small — flag mainly affects events escaping dedup (TTL expiry, cache restarts, etc.)
• 🟡 (16:25) Assistant identified the LARGE-drop scenario: user's processor attached to a REPROCESSING consumer (like events-reprocessing) where most events are already in nodestore by design. There, without the flag every reprocess fires event_accepted; with the flag, almost none do. So a large drop on the reprocess consumer is EXPECTED behavior, not a bug
• 🟡 (16:25) Assistant proposed diagnostic question: which consumer is the user's event_accepted receiver attached to? If events.ingest-consumer → flag impact should be modest, drop likely has another cause. If events-reprocessing (or similar reprocess consumer) → drop is expected, processor is attached to wrong consumer for forwarding new accepted events
• 🟡 (16:25) Assistant proposed concrete verification steps before touching config: check the consumer class the @receiver(event_accepted) is loaded in, and verify whether that consumer's process is launched with --reprocess-only-events-not-in-nodestore. Offered to look at where event_accepted receivers typically get registered to confirm the right consumer
• 🟡 (16:25) Assistant offered to investigate where event_accepted receivers are typically registered in the Sentry codebase to confirm which consumer is the appropriate home for the user's downstream processor