Open
Description
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
.
- The below query won't return result because of time range.
{
traces(
type: API_TRACE
between: {
startTime: "2020-08-22T06:43:05.358Z"
endTime: "2020-08-22T08:43:05.358Z"
}
filterBy: [
{
operator: EQUALS
value: "b210fcf03d5eb036"
type: ID
idType: API_TRACE
}
]
) {
results {
id
}
}
}
Result:
{
"data": {
"traces": {
"results": []
}
}
}
- But the same query without time range will work fine and give us trace.
{
traces(
type: API_TRACE
filterBy: [
{
operator: EQUALS
value: "b210fcf03d5eb036"
type: ID
idType: API_TRACE
}
]
) {
results {
id
}
}
}
Why is this helpful?
- go to trace feature: common in other tracing systems like zipkin, as logs have trace IDs so pasting one into the UI
- not sure this would be in hypertrace UI or hypertrace core UI
- end-to-end smoke test: also common is the ability to read back via api, what you've written, as HT has two api layers (gRPC and GraphQL) we should execute this in GraphQL
- that's this issue, which might also belong in hypertrace core graphql not sure
- reduce perceived complexity. there are a number of complexity issues, some caused by tech choices, some our choices within them. Being able to show the simplest api simply is also rationale. For example, with a simpler query, users can fetch a trace by ID without POST body syntax.