Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat(EAP): Trace Item resolvers (#6732)
### 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: ``` RPC Flask Endpoint -> RPCEndpoint.execute() -> Snuba query pipeline ``` After: ``` /-> EAP resolver -> Snuba query pipeline (or whatever else) RPC Flask Endpoint -> RPCEndpoint.execute() -> Uptime resolver -> Snuba query pipeline (or whatever else) \-> Errors resolver -> Snuba query pipeline (or whatever else) ``` For rationale, please read [this doc](https://www.notion.so/sentry/Where-does-RPC-Entity-specific-code-live-1238b10e4b5d806bb328d37c5f3bf522) ### How it works: Every EAP endpoint has a `get_resolver` method based on the `TraceItemName` 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: ``` snuba/web/rpc/v1/resolvers |->R_eap_spans |->R_uptime |->R_logs |->R_etc ``` 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 --------- Co-authored-by: getsantry[bot] <66042841+getsantry[bot]@users.noreply.github.com>
- Loading branch information