-
-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(EAP): Trace Item resolvers #6732
Conversation
3d283d7
to
07f5413
Compare
❌ 1 Tests Failed:
View the top 1 failed tests by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
class ResolverAttributeNames( | ||
TraceItemDataResolver[ | ||
TraceItemAttributeNamesRequest, TraceItemAttributeNamesResponse | ||
] | ||
): | ||
@classmethod | ||
def endpoint_name(cls) -> str: | ||
return "AttributeNames" | ||
|
||
|
||
class ResolverAttributeValues( | ||
TraceItemDataResolver[ | ||
TraceItemAttributeValuesRequest, TraceItemAttributeValuesResponse | ||
] | ||
): | ||
@classmethod | ||
def endpoint_name(cls) -> str: | ||
return "AttributeValues" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also implement resolvers for these in the future (subsequent PR)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolutely
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a few questions, but overall this looks good. Nice work!
) -> "Type[TraceItemDataResolver[Tin, Tout]]": | ||
return cast( | ||
Type["TraceItemDataResolver[Tin, Tout]"], | ||
getattr(cls, "_registry").get_class_from_name( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I'm missing something, but where is this _registry attribute being set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in the RegisteredClass metaclass
return cast( | ||
Type["TraceItemDataResolver[Tin, Tout]"], | ||
getattr(cls, "_registry").get_class_from_name( | ||
f"{cls.endpoint_name()}__{trace_item_name}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my understanding trace_item_name
is an enum, so won't this evaluate to something like "TraceItemTable__0"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
correct
65806d1
to
d962e4e
Compare
Context
In order to make room for new kinds of TraceItems (e.g. uptime monitors, errors, logs, etc),add a layer of indirection to the RPC layer
Before:
After:
For rationale, please read this doc
How it works:
Every EAP endpoint has a
get_resolver
method based on theTraceItemName
passed in the request meta. A resolver has the same inputs and outputs as the RPCEndpoint.For each endpoint in EAP, there is a resolver class:
https://github.com/getsentry/snuba/pull/6732/files#diff-c018ef30d919d555c5e69908ce74e5f9144d613de3588a48d849f8c757b58628R22-R53
For each TraceItem we have, we implement the appropriate resolvers, this PR moves EndpointTraceItemTable and EndpointTimeSeries implementations for EAP spans into resolver implementations.
Resolvers are picked up automatically if they follow the directory structure:
Implementing resolver classes in these directories will ❇️ just work ❇️ without needing to change endpoint code.
Outstanding things
It's not clear yet what is really "common" and what is not. We will figure this out through the course of doing this work