Improving Previous/Next Event Query
- Dominant language
- Python
- Stars
- 44.8k
- Forks
- 4.9k
- Avg merge
- 22h 21m
- Merged PRs (30d)
- 586
Description
Right now our query that fetches the next previous / next event which is used on the issue details page is not ideal. it will scan a lot of data because it is not efficient. The details on this are listed in this PR:
https://github.com/getsentry/sentry/pull/79365, and follow up https://github.com/getsentry/sentry/pull/79904
The problem is that the fix i attempted doesn't always return the previous/next event. Every time I tried to release it, @roggenkemper would find a bug with it, and I would have assumed the tests I wrote covered everything, but it is not so.
Here's how I'd go about Fixing this:
1) convert the option `eventstore.adjacent_event_ids_use_snql` to a flag which uses flagpole. from there, you can enable the feature only for yourself.
2) Click around sentry issues hitting previous/next event until you find an issue which for there are many issues, but a previous/next event is not returned.
Once you hit the issue, record the time at which you made the query. check to see if you have a sentry trace for that request, and if so you can use the SnQL in the trace. If there is not, you can use the snuba-admin tool to track down your raw query via the query log.
From there, you can query clickhouse in snuba-admin, to debug what is wrong about the query.
to debug what queries happen locally, you can run sentry with `SENTRY_SNUBA_INFO=1 sentry devserver...`. and can tail the clickhous server logs with `docker exec -it snuba-clickhouse-1 tail -f /var/log/clickhouse-server/clickhouse-server.log`.
Contributor guide
Research direction
Start with PRs 79365 and 79904 and the eventstore.adjacent_event_ids_use_snql option. Enable the option through Flagpole, reproduce a missing previous or next event on the issue details page, then inspect the request trace or use snuba-admin and the query logs to debug the SnQL or ClickHouse query. Done means the query remains efficient and reliably returns adjacent events across the reproduced cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, databases
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100