ref(api): Report client_kind attributes from every endpoint - #123907
Merged
Conversation
Contributor
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit be65ac1. Configure here.
The caller attribution wiring lived in OrganizationEventsEndpointBase.convert_args, so only the ~44 events endpoints reported it. Move it to a single call site in Endpoint.dispatch, driven by an overridable client_kind_organization hook: the default reads the organization kwarg that every org-scoped base populates, and ProjectEndpoint reads it off the project it already select_relateds. Widens get_client_kind to accept RpcOrganization so control-silo organization endpoints are covered too. Coverage goes from ~44 endpoints to 300+, with no per-endpoint wiring.
TeamEndpoint and GroupEndpoint resolve their organization off the related object rather than into the organization kwarg, so the default hook left 38 endpoints unattributed. Both already select_related the organization, so neither override costs a query.
DominikB2014
force-pushed
the
ref/client-kind-attributes-all-endpoints
branch
from
September 9, 2026 14:42
94752f5 to
37caa88
Compare
Contributor
Author
|
@cursor review |
DominikB2014
marked this pull request as ready for review
September 9, 2026 14:56
skaasten
reviewed
Sep 9, 2026
Per review feedback: the organization was only ever needed for the feature flag, not for classification. Moving that check up to the dispatch call site lets get_client_kind and set_client_kind_attributes drop the organization parameter entirely, along with the Organization/RpcOrganization widening and both model imports. The client_kind_organization hook stays, so a base that resolves its organization some other way is still covered and plain Endpoint subclasses that populate the organization kwarg keep working without per-base wiring. At GA the hook and the features.has call delete together, leaving one unconditional call. Ordering matters here: the opt-in is checked before set_client_kind_attributes, so a client_kind_scope declaration cannot report for an org that never enabled the feature. That guarantee used to be enforced inside get_client_kind; test_a_declared_kind_does_not_bypass_the_opt_in now pins it at dispatch.
DominikB2014
force-pushed
the
ref/client-kind-attributes-all-endpoints
branch
from
September 9, 2026 15:39
8f02e7f to
9ceef94
Compare
Every base that resolves an organization already assigns it to request._request.organization, and DRF proxies attribute lookups to the underlying HttpRequest, so dispatch can read it directly. access_log.py already reads it the same way. That removes the client_kind_organization hook and its three overrides -- no extension point on Endpoint for what is temporary scaffolding. kwargs is still consulted first, because the SentryApp bases populate only that and never touch the request. The hook's unit tests are replaced by real requests against organization, project, team and issue endpoints, which is the only honest way to pin coverage now that there is no seam. Removing the request fallback fails the project, team and issue cases.
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.

The
client_kindcaller-attribution wiring lived inOrganizationEventsEndpointBase.convert_args, so only the ~44 events endpoints reported it. This moves it to a single call site inEndpoint.dispatch, which reads the organizationconvert_argsalready resolved — from theorganizationkwarg, or offrequest.organization, which every organization-scoped base assigns and whichaccess_logalready reads the same way.The organization is used only to check the opt-in.
get_client_kindderives everything else from the request and no longer takes one, which also drops theOrganization/RpcOrganizationhandling fromclient_kind.py. Ordering matters here: the flag is checked beforeset_client_kind_attributes, so aclient_kind_scopedeclaration can't report for an org that never enabled the feature.Coverage goes from ~44 endpoints to 300+ — organization, project, team and issue endpoints — with no per-endpoint wiring, and new endpoints are picked up automatically. Everything stays behind the existing
organizations:api-client-kind-checkflag, so the only work added to an unflagged request is onefeatures.hascall.I ran this locally and can see it logging the derived
client_kindfor requests as they come in.One behavior change worth noting: attributes are now recorded only after
convert_argscompletes, so an endpoint whoseconvert_argsraises aftersuper()no longer reports.OrganizationEventDetailsEndpointis the only affected subclass.