Hi,
We have an issue with the error IDs provided by sentry, and their lifetimes.
We use sentry for a desktop application. When an unexpected error occurs we always immediately send the error to sentry in the background. We then also allow the user to report the error manually by creating a GitHub issue, so that they can provide more context, ie. what were they doing when it occurred, is it reproducible etc.
When we post an error to sentry, we get a reply like this from the API:
{"id":"e059ce4bc0464fee8d159b0b78f6a489"}
In the past, we’ve been able to lookup errors using this id with the following URL template:
https://sentry.io/${organization}/${project}/?query=${id}
So, for the example id:
https://sentry.io/${organization}/${project}/?query=e059ce4bc0464fee8d159b0b78f6a489
We’ve used this in the issues we create. By including the id (with link) we can easily find the exact error the user encountered (see https://github.com/defold/editor2-issues/issues/1223 for an example).
We’ve always found that after some time, the search query above fails to return any results, ie. it’s unable to find the grouped error using the original reported error id. However, recently this has gotten a lot worse, and we frequently find that we are unable to lookup events created just one or two days ago.
This is starting to become a deal breaker for us.
My question is: are we doing something wrong? Is there another way to accomplish what we want using sentry?
Thanks,
Ragge