-
Notifications
You must be signed in to change notification settings - Fork 68
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
experimental: adjust the query client interface, remove unused code #1211
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the 3 prs look good, I think we can probably put them all together? But yeah seems like a good improvement!
func NewErrorQDR(req QueryDataRequest, err error) *backend.QueryDataResponse { | ||
qdr := backend.NewQueryDataResponse() | ||
for _, q := range req.Queries { | ||
qdr.Responses[q.RefID] = backend.ErrDataResponse(backend.StatusBadRequest, err.Error()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's weird that the existing code did this btw... like what if the status code from the response was a 429 it would get lost kind of? But also my understanding is maybe that's already happening so i guess ok to keep it? haha.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, i admit, we kind of rely on knowing (or thinking that we know 😁 ) the possible http-codes.
i did some digging for how /api/ds/query
does this, and it's like this:
- https://github.com/grafana/grafana/blob/58df80e542201b91e480c3425ecce6dcd792c1d3/pkg/api/ds_query.go#L80
- this seems to be the point where QueryDataResponse (QDR) structures become http-status-codes and json... as you can see, it checks if we have an
error
or a QDR- if we have an
error
, then it goes to https://github.com/grafana/grafana/blob/58df80e542201b91e480c3425ecce6dcd792c1d3/pkg/api/ds_query.go#L24, and , interestingly, checks for the error being a http404-error, and handles that specially. the rest seems to be auth-related. and if nothing matches, http500. - if we don't have an
error
, meaning we have aQDR
, then we go to https://github.com/grafana/grafana/blob/58df80e542201b91e480c3425ecce6dcd792c1d3/pkg/api/ds_query.go#L86, and we check if the QDR has any DataResponses in it with an error. if yes, http400, else http200.
- if we have an
- this seems to be the point where QueryDataResponse (QDR) structures become http-status-codes and json... as you can see, it checks if we have an
so in short, if we have a QDR, then it's http400 or http200, if we don't have a QDR, we check for maybe-http404, some auth-cases, else http500 😄
... of course it's still possible that we'll find a scenario that we cannot represent with the current approach 😿 , i guess then we go back to the drawing board again..
50b1c76
to
84e1084
Compare
84e1084
to
aef7827
Compare
will use a different approach, closing for now |
changes to certain structures in
experimental
:QueryDataClient
to be a better fit for it's consumers. (example consumer: datasources: querier: adjust the query-client grafana#99805)simpleHTTPClient
implementation, and it's dependencies, as it is not used anymore.