DashboardsentryDistillation

Distillation

ID: aa3eb5be-67ab-4a99-9c2f-317e0f3085e8
Session: 0rWXqG93IDSI
Generation: 0
Tokens: 1504
R_compression: 12.492
C_norm: 0.000
Archived: No
Created: 2026-07-30 15:48:22
Source IDs:
["cf2c9ed61027b935f4048f0935b843df","c692b636eb9b8c16318b8fe707bc51b4"]

Observations

<observations> Date: July 30, 2026 * 🔴 (15:46) User stated the core principle: always scope queries by organization/project. When querying resources, ALWAYS include `organization_id` and/or `project_id` in query filters — never trust user-supplied IDs alone. Correct pattern: `Resource.objects.get(id=request.data["resource_id"], organization_id=organization.id)` * 🔴 (15:46) User stated the rule for bulk requests: NEVER query the database in `serialize()` for bulk requests, always use `get_attrs()`. Triggered by the "User wants to add a Celery task" scenario * 🔴 (15:46) User stated: never suggest adding a default value to `options.get()` calls. All options are registered via `register()` in `defaults.py` which requires a default value; the options system always returns the registered default if no value is set, making a second default parameter redundant and potentially inconsistent * 🔴 (15:46) User stated for function signatures: always use abstract types (e.g. `Sequence` over `list`) for input parameters and use specific return types (e.g. `list` over `Sequence`) * 🔴 (15:46) User stated structured logging convention: use `logger.info("user.action.complete", extra={"user_id": user.id, "action": "login", "ip_address": request.META.get("REMOTE_ADDR")})` pattern * 🔴 (15:46) User stated tracing convention: use child spans via `with start_span(name="event_manager.save", op="save") as span: set_span_tag(span, "platform", platform); set_span_data(span, "rows_count", len(rows))` — `set_span_tag` and `set_span_data` helpers * 🔴 (15:46) User stated: see Feature Flags (FlagPole) in `/AGENTS.md` for registration, the `features.has(...)` check, and test usage * 🔴 (15:46) User stated: "When in Doubt" guidance exists for composite index strategy — match query patterns (full content elided in segment) * 🟡 (15:46) File traced: `src/sentry/ingest/consumer/processors.py`. Contains `event_accepted.send_robust()` call at lines 313-316 inside `process_event`. Key imports include `UsageUnit` from usageaccountant (line 11), `eventstore` from sentry.services (line 23), and `TransactionStageStatus`, `track_sampled_event` from sentry.utils.event_tracker (line 35). Setting `SENTRY_INGEST_CONSUMER_APM_SAMPLING` used as default (line 61) * 🟡 (15:46) Identified 8 conditions where `event_accepted.send_robust()` is NOT called in `process_event`: 1. **Duplicate event** (lines 125-131): when `cache.get(deduplication_key)` returns cached value, early return without signaling 2. **Killswitch `store.load-shed-pipeline-projects` matches** (lines 133-144): early return 3. **Killswitch `store.load-shed-parsed-pipeline-projects` matches** (lines 162-175): early return 4. **JSON parsing fails** (line 149-150): `orjson.loads(payload)` raises — OUTSIDE the try block (try starts at line 179), so propagates up directly (not wrapped as Retriable) 5. **`reprocess_only_stuck_events` and event NOT in processing_store** (lines 187-188): returns early inside try block 6. **`reprocess_only_events_not_in_nodestore` and event IS in nodestore** (lines 195-196): returns early 7. **`Organization.DoesNotExist`** (lines 238-246): returns early 8. **Any exception raised before line 313** within try block (lines 179-313): caught by except block, re-raised as Retriable (or KeyError directly) — event_accepted NOT signaled * 🟡 (15:46) Identified failure modes for `event_accepted.send_robust()`: - Exception during dispatch before line 313 (e.g., `cache.set` failure at line 309-310) → caught, re-raised as Retriable → entire message retried → potential duplicate `event_accepted` signals on retry - `KeyError` in try block (e.g., missing event_id) → re-raised directly (NOT Retriable), event_accepted NOT signaled - `send_robust` itself catches receiver exceptions, so individual signal receiver failures do NOT propagate * 🟡 (15:46) Recent git changes in `processors.py` (within 2 months) that may affect `event_accepted`: 1. `d7fcb07bc42 feat(ingest): add option to reprocess events not in nodestore (#120133)` — adds `reprocess_only_events_not_in_nodestore` parameter and a new early-return path (lines 192-196) that does NOT signal event_accepted 2. `c3d9b35f46c Revert "ref(feedback): emit metric instead of outcome for ingest denylist (#97970)" (#119793)` — revert of feedback denylist outcome change 3. `99e5d7c5133 fix(feedback): don't orphan feedback payloads in the processing store (#119642)` — feedback path skips Redis store; should not affect event_accepted 4