feat(sentry): add worker-side Sentry webhook job dispatch

[aaight]

Summary

• Adds SentryJobData interface to src/worker-entry.ts matching the router's SentryJob type structure
• Adds 'sentry' case to dispatchJob() switch statement that calls processSentryWebhook()
• Creates src/triggers/sentry/webhook-handler.ts with processSentryWebhook() following the thin-wrapper pattern from Trello/JIRA handlers
• Includes SentryJobData in the JobData union type

This fixes a bug where Sentry webhook jobs enqueued by the router were being dropped with an "Unknown job type: sentry" error because dispatchJob() had no 'sentry' case.

Card: https://trello.com/c/69c1b02b331142dd91419576

Test plan

• tests/unit/worker-entry.test.ts — added test: routes sentry job to processSentryWebhook with payload, projectId, registry, and triggerResult
• tests/unit/triggers/sentry-webhook-handler.test.ts — new file testing processSentryWebhook():
  • Loads project config by projectId and dispatches with sentry source
  • Creates TriggerContext with source sentry and given payload
  • Logs warning and returns without dispatching when project is not found
  • Dispatches even when triggerResult is provided
  • Logs debug message when triggerResult is provided
• All existing worker-entry tests continue to pass (21 tests)

🤖 Generated with Claude Code

🕵️ claude-code · claude-sonnet-4-6 · run details

[codecov]

Codecov Report

❌ Patch coverage is 93.50649% with 5 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/triggers/sentry/webhook-handler.ts	91.93%	5 Missing ⚠️

📢 Thoughts on this report? Let us know!

[nhopeatall]

Summary

The dispatch plumbing (SentryJobData, dispatchJob case) is correct and follows existing patterns. However, processSentryWebhook silently discards the pre-computed triggerResult from the router, always re-dispatching through the registry instead. This breaks the router→worker contract that every other handler (Trello, JIRA, GitHub) follows.

Architecture & Design

• [BLOCKING] triggerResult is accepted but never used (src/triggers/sentry/webhook-handler.ts): The router computes a TriggerResult via SentryRouterAdapter.dispatchWithCredentials(), serializes it into the BullMQ job, and the worker passes it to processSentryWebhook. But the handler only logs triggerResult — it always calls registry.dispatch(ctx) unconditionally, discarding the pre-computed result. Every other webhook handler uses triggerResult as a short-circuit:

  • Trello/JIRA: processPMWebhook → resolveTriggerResult() returns preResolvedResult directly when non-null (see src/pm/webhook-handler.ts:72-77)
  • GitHub: processGitHubWebhook checks if (triggerResult) and assigns result = triggerResult (see src/triggers/github/webhook-handler.ts:254-258)

  This means Sentry webhooks always re-evaluate triggers on the worker, which is wasteful and could produce different results if registry state diverges between router and worker. The handler should follow the same pattern: use triggerResult when provided, fall back to registry.dispatch(ctx) otherwise.

  Additionally, the handler dispatches triggers but never executes the matched agent — it calls registry.dispatch(ctx) which returns a TriggerResult, but that return value is discarded. In contrast, Trello/JIRA handlers call runAgentWithCredentials and GitHub calls runGitHubAgent with the result. This means Sentry webhooks match triggers but never actually run agents.

Code Issues

Should Fix

• src/worker-entry.ts:75 — The eventType JSDoc comment says 'event_alert' | 'metric_alert' but the router-side SentryJob type in src/router/queue.ts:55 lists 'event_alert' | 'metric_alert' | 'issue'. The worker-side comment should match the router-side type to avoid confusion.

Test Issues

• tests/unit/triggers/sentry-webhook-handler.test.ts — The test "dispatches even when triggerResult is provided" asserts that registry.dispatch is always called regardless of triggerResult. This test is passing, but it validates the buggy behavior. Once the handler is fixed to use triggerResult when provided (skipping registry.dispatch), this test should assert the opposite: that registry.dispatch is NOT called when triggerResult is provided.

🕵️ claude-code · claude-opus-4-6 · run details

[nhopeatall]

Summary

LGTM — The implementation correctly fixes the dropped Sentry webhook jobs by adding the missing dispatchJob case and a well-structured handler. Tests are comprehensive and CI is green.

Minor Observations

• Doc comment not updated: src/worker-entry.ts lines 6 and 11 still list job types as "Trello, GitHub, or JIRA" — Sentry should be added to both the description and JOB_TYPE env var docs.
• No withGitHubToken scope: Unlike the Trello/JIRA/GitHub handlers that go through runAgentWithCredentials (which sets up a scoped GitHub Octokit client), the Sentry handler calls runAgentExecutionPipeline directly. This is fine for the current alerting agent (which doesn't require SCM capabilities), but if a future Sentry-triggered agent needs GitHub access (e.g., auto-creating PRs), the missing GitHub client scope would cause failures in linkPRPostExecution. Worth a code comment noting this intentional limitation.
• Not re-exported from triggers/index.ts: Minor inconsistency — processGitHubWebhook and processJiraWebhook are barrel-exported from triggers/index.ts, while processSentryWebhook is imported directly. This matches the existing processTrelloWebhook pattern though, so not a real issue.

🕵️ claude-code · claude-opus-4-6 · run details