Skip to content

Refactor event processing pipeline into type-specific handlers#120574

Draft
mwarkentin wants to merge 3 commits into
masterfrom
claude/processor-architecture-review-sj1fou
Draft

Refactor event processing pipeline into type-specific handlers#120574
mwarkentin wants to merge 3 commits into
masterfrom
claude/processor-architecture-review-sj1fou

Conversation

@mwarkentin

Copy link
Copy Markdown
Member

Description

This PR refactors the process_event function to improve code organization and maintainability by extracting event type-specific processing logic into dedicated handler functions.

Changes

New helper functions:

  • _lookup_organization(): Fetches and caches the organization on a project, with proper error handling
  • _set_dedup_and_signal(): Handles deduplication cache setting and event_accepted signal emission
  • _process_transaction_event(): Dedicated handler for transaction events
  • _process_feedback_event(): Dedicated handler for feedback events
  • _process_default_event(): Dedicated handler for default pipeline events (error, csp, hpkp, etc.)

New constant:

  • _DEFAULT_PIPELINE_EVENT_TYPES: A frozenset of event types that use the standard preprocess → symbolicate → save pipeline

Refactored process_event() function:

  • Simplified main logic by dispatching to type-specific handlers based on event type
  • Added explicit handling for unknown event types with logging and metrics
  • Improved code readability and reduced nesting depth
  • Maintains all existing behavior and error handling

Benefits

  • Improved maintainability: Each event type's processing logic is isolated and easier to understand
  • Reduced complexity: The main process_event() function is now a clear dispatcher rather than a monolithic handler
  • Better testability: Individual handlers can be tested in isolation
  • Clearer intent: The code explicitly shows which event types follow which processing paths

Test Plan

Existing tests should continue to pass as this is a refactoring that preserves all existing behavior. The dispatch logic ensures events are routed to the same handlers as before, just through a cleaner code path.

https://claude.ai/code/session_01LtwaTTFKxXUAqBUqV79zpw

claude added 2 commits July 23, 2026 18:24
Extract three handler functions from the monolithic process_event:
_process_transaction_event, _process_feedback_event, _process_error_event.

Each handler is self-contained for its event type's pipeline, eliminating
footguns where code for one type accidentally affects another (e.g., feedback
data being stored in Redis but never consumed or cleaned up). The process_event
function now acts as a thin dispatcher: shared pre-processing (deduplication,
killswitches, JSON parse) followed by routing to the appropriate handler.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LtwaTTFKxXUAqBUqV79zpw
…uard unknown types

The default handler processes errors, security reports (csp, hpkp, expectct,
expectstaple, nel), generic events, and default/untyped events — not just
errors. Rename to _process_default_event to reflect this.

Add an explicit allowlist of known event types for the default pipeline. Unknown
types now log an error and emit a metric instead of silently flowing through the
error pipeline.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LtwaTTFKxXUAqBUqV79zpw
@github-actions github-actions Bot added the Scope: Backend Automatically applied to PRs that change backend components label Jul 24, 2026
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LtwaTTFKxXUAqBUqV79zpw
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Backend Automatically applied to PRs that change backend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants