Skip to content

fix: group integration webhook 500s in Sentry and raise level to warning#5087

Draft
cursor[bot] wants to merge 1 commit into
mainfrom
cursor/agent-f542106c
Draft

fix: group integration webhook 500s in Sentry and raise level to warning#5087
cursor[bot] wants to merge 1 commit into
mainfrom
cursor/agent-f542106c

Conversation

@cursor
Copy link
Copy Markdown
Contributor

@cursor cursor Bot commented May 30, 2026

Context

A Sentry issue (HTTP 500 /api/v1/integrations/e931a088-90c5-4fa2-9b30-fc7d9d586723/webhook, link) was reported at info level for a single integration UUID. Inspecting pkg/public/middleware/logging.go showed two problems with how server errors get reported to Sentry:

  1. captureHTTPError uses the concrete r.URL.Path as the Sentry message, so every distinct integration UUID produces a new Sentry issue. The /api/v1/integrations/{integrationID}/webhook endpoint (used by GitHub and Dash0 integrations) generates one Sentry issue per failing integration, fragmenting the data and making aggregate trends invisible.
  2. hub.CaptureMessage(...) is called without setting a level, so 5xx events come in as info. They get filtered out of Sentry's default error views, which explains why this regression slipped in as a low-signal event.

Change

  • Redact UUID-shaped path segments (canonical 8-4-4-4-12 hex form) before composing the Sentry message, so all integration webhook 500s collapse into a single issue titled HTTP 500 /api/v1/integrations/{id}/webhook. Other endpoints (e.g. /api/v1/canvases/{id}/nodes/{id}) benefit from the same grouping.
  • Set the Sentry event level to Warning for captured 5xx responses so they surface in the standard error filters.
  • Attach the original concrete path as an http.path tag (on both the error and panic capture paths) so engineers can still drill into which specific integration / canvas / node was failing without losing aggregation.

This is purely an observability fix; behavior of the integration webhook handlers themselves is unchanged. Once landed, future 500s on /api/v1/integrations/{integrationID}/webhook will aggregate into one warning-level Sentry issue with the specific UUIDs visible in the tags/request context, which will make it much easier to diagnose the underlying integration handler bug.

Test plan

  • New unit tests in pkg/public/middleware/logging_test.go cover redactPathIDs (canonical UUIDs, multiple UUIDs in one path, uppercase UUIDs, paths without UUIDs) and groupingPathForRequest (the integration webhook scenario and a non-UUID path).
  • Existing TestShouldCaptureHTTPError cases still pass.
  • go test ./pkg/public/middleware/... passes locally for the targeted tests.
Open in Web Open in Cursor 

The Sentry HTTP error capture used the raw URL path as the issue title,
so every integration webhook 500 created a new Sentry issue keyed on the
integration UUID (e.g. HTTP 500
/api/v1/integrations/e931a088-90c5-4fa2-9b30-fc7d9d586723/webhook).
This both fragmented the data and reported the error at the default Info
level, which hid real 5xx incidents in Sentry's default filters.

Redact UUID-shaped path segments before forming the Sentry message so
that all integration webhook 500s collapse into a single issue (HTTP 500
/api/v1/integrations/{id}/webhook), set the event level to Warning so
5xx events surface alongside other server warnings, and attach the
original path as an http.path tag so we can still drill into specific
failing integrations.
@superplanehq-integration
Copy link
Copy Markdown

👋 Commands for maintainers:

  • /sp start - Start an ephemeral machine (takes ~30s)
  • /sp stop - Stop a running machine (auto-executed on pr close)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant