-
Notifications
You must be signed in to change notification settings - Fork 7
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
Fetching records by ID should be time agnostic #19
Comments
yep I don't think any of the tracing systems would be able to get by without a trace ID index. There may be some practical limitations, such as how far back to look for a trace ID and not since 1970, but right now Zipkin etc wouldn't require a range query to get a trace by ID. |
We've discussed prior and do need this API, but as planned it should simplify down to:
Right now, the HT UI doesn't need this so it hasn't been a priority. It will require query layer changes before we can support this in graphql though. |
maybe we can track this independently as for example a ui component that
jumps to trace by ID will need it.
for other use cases this is annoying especially with test data as it is
often old (some are a couple years old). I wonder if we can use dummy date
like jan 1 2015 until 2025 until the api exists? that way it doesnt need
to change except trace ID until this is resolved.
would that work?
|
It would definitely be feasible to implement this in graphql with a dummy time range on the internal query, just gets to be a question of relative priority (is it important to get this out in some form immediately, vs spending more time to wait for a better implementation), and whether there are performance implications to that type of implementation (I don't know, but I would suspect yes). |
I added rationale to the description. I think for now, we can try the dummy range to allow smoke tests and "simplest api" instructions to operate without having to know up front the time range the trace is in. Meanwhile, the internal implementation probably should go forward when resources allow. Otherwise, we should mark this help-wanted if we don't have resources, so someone else can do it. |
Fetching records by ID is currently time range dependent. We observed that time range is essential for each query we do. But in case I am searching for trace using Trace ID which is unique parameter it's going to return only one trace but if that trace is not there in that time range, I won't get that back.
ex: If I am searching for Trace with ID
b210fcf03d5eb036
.Result:
Why is this helpful?
cc: @adriancole @skjindal93
The text was updated successfully, but these errors were encountered: