ref(gitlab): Namespace webhook log attributes and add malformed-token context#117959
Merged
Conversation
… context GitLab webhook failure logs were hard to debug in the Logs explorer: org_ids was logged as a list, which serializes as an EAP "array" attribute that the explorer won't surface as a queryable column (the attribute discovery endpoint only enumerates string/number/boolean types). The malformed-token path also had no way to identify the source, since a malformed token can't resolve the integration or org. Join org_ids into a comma-separated string so it's a filterable column, and namespace every dispatch-path log attribute under a single "webhook." prefix (user_agent, event_type, reason, integration.*, org_ids, repo.*) so they render as one grouped tree alongside the SDK's code.*/thread.* attributes. For the malformed-token case, best-effort parse the request body — which is independent of the token — to attach the source repo/owner (path_with_namespace, namespace, web_url, project_id) plus object_kind and user. No behavior change to webhook responses. Co-Authored-By: Claude <noreply@anthropic.com>
billyvg
commented
Jun 17, 2026
| "id": integration.id, # This is useful to query via Redash | ||
| "status": integration.status, # 0 seems to be active | ||
| }, | ||
| "org_ids": [install.organization_id for install in installs], |
Comment on lines
-671
to
-678
| "integration": { | ||
| # The metadata could be useful to debug | ||
| # domain_name -> gitlab.com/getsentry-ecosystem/foo' | ||
| # scopes -> ['api'] | ||
| "metadata": integration.metadata, | ||
| "id": integration.id, # This is useful to query via Redash | ||
| "status": integration.status, # 0 seems to be active | ||
| }, |
srest2021
approved these changes
Jun 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
GitLab webhook failure logs were hard to debug in the Logs explorer. Two concrete problems:
org_idswasn't queryable. It was logged as alist[int], which the SDK serializes as an EAParray-typed attribute. The logs attribute-discovery endpoint only enumeratesstring/number/booleantypes (POSSIBLE_ATTRIBUTE_TYPES), so array attributes never surface as a selectable/filterable column.org_idsis only added after the integration is resolved — but a malformedHTTP_X_GITLAB_TOKENcan't be parsed to resolve the integration/org in the first place, so those logs carried nothing identifying the sender.Changes
org_ids→ comma-joined string so it's a filterable Logs column.webhook.—user_agent,event_type,reason,integration.{metadata,id,status},org_ids,repo.*,user.username. Dotted keys render as one grouped tree in the explorer (the UI splits attribute keys on.), cleanly separated from the SDK'scode.*/thread.*attributes, while each leaf stays individually queryable (e.g.webhook.repo.path:"group/repo").webhook.repo.path/namespace/web_url/project_id),webhook.object_kind, andwebhook.user.username. Fully defensive: bad/non-JSON body → no extra keys, never breaks the response.No behavior change to webhook responses (status codes and reason phrases are byte-identical).
Test Plan
test_invalid_tokento assert the malformed-token log carries the body-derivedwebhook.repo.*/webhook.object_kindattributes.pytest tests/sentry/integrations/gitlab/test_webhook.py— 31 passed.Note: the new
webhook.*attributes apply to freshly-ingested logs going forward, not retroactively.