Skip to content
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

Fix(query-frontend): /label/<name>/values endpoint to use right set of middlewares #6072

Merged
merged 3 commits into from
May 2, 2022

Conversation

kavirajk
Copy link
Contributor

@kavirajk kavirajk commented May 2, 2022

What this PR does / why we need it:

Previously, only /label/ and /labels endpoint were using correct tripperware middleware
on the query frontend(e.g: stats collector middleware)

This PR fixes it for /label/<name>/values endpoint as well.

This is useful to support metrics.go stats middleware for label/{name}/values endpoint

Signed-off-by: Kaviraj kavirajkanagaraj@gmail.com

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:
Related to #5971

Checklist

  • Documentation added
  • Tests updated
  • Is this an important fix or new feature? Add an entry in the CHANGELOG.md.
  • Changes that require user attention or interaction to upgrade are documented in docs/sources/upgrading/_index.md

…dleware

Previously, only `/label/` and `/labels` endpoint were using correct tripperware middleware
on the query frontend(e.g: stats collector middleware)

This PR fixes it for `/label/<name>/values` endpoint as well.

This is useful to support `metrics.go` stats middleware for `label/{name}/values` endpoint as well.

Signed-off-by: Kaviraj <kavirajkanagaraj@gmail.com>
@kavirajk kavirajk requested a review from a team as a code owner May 2, 2022 12:58
@kavirajk kavirajk changed the title Fix(query-frontend): /label/<name>/values endpoint to use right mid… Fix(query-frontend): /label/<name>/values endpoint to use right set of middlewares May 2, 2022
Copy link
Contributor

@dannykopping dannykopping left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -232,7 +232,7 @@ func getOperation(path string) string {
return QueryRangeOp
case strings.HasSuffix(path, "/series"):
return SeriesOp
case strings.HasSuffix(path, "/labels") || strings.HasSuffix(path, "/label"):
case strings.HasSuffix(path, "/labels") || strings.HasSuffix(path, "/label") || strings.HasSuffix(path, "/values"):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function feels a bit flimsy, and could introduce some interesting bugs in the future.
We should refactor this at some point

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding a test!

@@ -232,7 +232,7 @@ func getOperation(path string) string {
return QueryRangeOp
case strings.HasSuffix(path, "/series"):
return SeriesOp
case strings.HasSuffix(path, "/labels") || strings.HasSuffix(path, "/label"):
case strings.HasSuffix(path, "/labels") || strings.HasSuffix(path, "/label") || strings.HasSuffix(path, "/values"):
Copy link
Contributor Author

@kavirajk kavirajk May 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q: Does anyone know why middeware chain was disabled for /labels/<name>/values endpoint on the query frontend?

We in fact have a test to lock that behaviour.
https://github.com/grafana/loki/blob/main/pkg/querier/queryrange/roundtrip_test.go#L390-L400 (which is the only test failing for this PR)

I wanted this support so that middlewares like metrics.go stats collector can work on this endpoints too. (#5971)

Any thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If no protest, I can remove that test!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I bet it was omitted by mistake

Signed-off-by: Kaviraj <kavirajkanagaraj@gmail.com>
Signed-off-by: Kaviraj <kavirajkanagaraj@gmail.com>
@pull-request-size pull-request-size bot added size/L and removed size/M labels May 2, 2022
@kavirajk kavirajk merged commit bb2e952 into main May 2, 2022
@kavirajk kavirajk deleted the kavirajk/fix-labels-op-tripperware-query-frontend branch May 2, 2022 15:00
kavirajk added a commit that referenced this pull request May 3, 2022
…el values endpoint

When encode/decode `http.Request` into `querybase.Request` we re-create request.Path.

Before this PR, both `/labels/` and `/labels/{name}/values` endpoint was decoding into same URL path `/labels/` before
forwarding to the querier. So it always returns label names as response.

This bug became visible after enabling all the middleware for `/labels/{name}/values` endpoint as well via #6072

Signed-off-by: Kaviraj <kavirajkanagaraj@gmail.com>
kavirajk added a commit that referenced this pull request May 3, 2022
…el values endpoint (#6084)

When encode/decode `http.Request` into `querybase.Request` we re-create request.Path.

Before this PR, both `/labels/` and `/labels/{name}/values` endpoint was decoding into same URL path `/labels/` before
forwarding to the querier. So it always returns label names as response.

This bug became visible after enabling all the middleware for `/labels/{name}/values` endpoint as well via #6072

Signed-off-by: Kaviraj <kavirajkanagaraj@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants