feat(tracing): Add debug endpoint for raw trace item response#116127
feat(tracing): Add debug endpoint for raw trace item response#116127mjq wants to merge 2 commits into
Conversation
|
🚨 Warning: This pull request contains Frontend and Backend changes! It's discouraged to make changes to Sentry's Frontend and Backend in a single pull request. The Frontend and Backend are not atomically deployed. If the changes are interdependent of each other, they must be separated into two pull requests and be made forward or backwards compatible, such that the Backend or Frontend can be safely deployed independently. Have questions? Please ask in the |
📊 Type Coverage Diff✅ No new type safety issues introduced. Coverage: 93.58% |
| @staticmethod | ||
| def get(request: Request, project: Project, item_id: str) -> Response: | ||
| """ | ||
| Like ProjectTraceItemDetailsEndpoint, but returns the raw |
There was a problem hiding this comment.
Looking at the logic in the ProjectTraceItemDetailsEndpoint, is the logic bw the that and this endpoint meant to be the same long term? If so, would it make sense extract the logic of each get endpoint into a helper? Smth like
def _build_trace_item_details_request(...):
serializer = ProjectTraceItemDetailsEndpointSerializer(data=request.GET)
...
return TraceItemDetailsRequest(...)
# ProjectTraceItemDetailsEndpoint endpoint
def get(...):
req = _build_trace_item_details_request(...)
resp = MessageToDict(snuba_rpc.trace_item_details_rpc(req))
...
return Response(resp)
# ProjectTraceItemDetailsRawEndpoint endpoint
def get(...):
if not superuser_has_permission(request):
return Response(status=403)
req = _build_trace_item_details_request(...)
resp = MessageToDict(snuba_rpc.trace_item_details_rpc(req))
return Response(resp)?
Then the tests could for the most part apply to 1 common fn instead too
There was a problem hiding this comment.
👍 @wmak suggested an alternative which is to add a debug param to the existing endpoint rather than making a new one, which is something I just learned we already do in other RPC-calling endpoints so it's an established pattern. Going to do that instead! But good call here anyway.
In general, but especially during our span streaming rollout, it's useful for debugging to be able to see the underlying data for a particular span before it is transformed by the Sentry API and frontend. This PR adds a superuser-only endpoint that returns the raw result from EAP's
TraceItemDetailsRPC.This will be hooked up to a superuser-only button on the span details pane in the trace waterfall, similar to how we have the link to see raw transaction JSON for transactions (except the audience for this will be superusers only).
🤖: Claude Code (Opus 4.6) used to generate the code, with human editing + review. All words my own.