-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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: make detected fields work for both json and proto #12682
Conversation
@@ -1610,7 +1610,7 @@ func (Codec) MergeResponse(responses ...queryrangebase.Response) (queryrangebase | |||
return &DetectedFieldsResponse{ | |||
Response: &logproto.DetectedFieldsResponse{ | |||
Fields: mergedFields, | |||
FieldLimit: fieldLimit, | |||
FieldLimit: 0, |
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.
is this intentional, hardcoding to 0?
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.
yes, the FieldLimit
is only needed in the merge code, so once we've merged we don't need to pass that back to the user
message DetectedFieldsResponse { | ||
repeated DetectedField fields = 1; | ||
uint32 fieldLimit = 2; | ||
uint32 fieldLimit = 2 [(gogoproto.jsontag) = "fieldLimit,omitempty"]; | ||
} |
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.
shouldn't we be defining an alternative message type for inter-service usage only, and using the base DetectedFieldsResponse
as the external response type?
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.
ideally yes, but I don't know how to do that without having to implement a new method on both the querier and query frontend, which also feels messy since the query frontend shouldn't be concerned with returning internal representations of anything.
I think I could probably learn from the quantile/probabilistic query types code you did. I can circle back on this once I've had a chance to get more familiar with that?
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.
discussed on slack, LGTM
127bc72
to
efafd51
Compare
What this PR does / why we need it:
This makes the new
/detected_fields
endpoint work for both JSON and protobuf encodings.#12491 adding splitting of detected fields queries. This is accomplished by serializing the hyperloglog sketches built in the queriers in the response so they can be merged in the query frontends. We don't want the serialized sketch in the JSON response from the frontend, so #12491 used a bit of a hack of defining a
-
json tag. This had the tradeoff of only allowing detected field splitting to work whenprotobuf
encoding was enabled. Because of this, we guarded the registration of the route on whether or notprotobuf
was set as the encoding type.This decision has already tripped some people up since
protobuf
in not the default, and raised concerns about OSS users, so this PR changes the strategy for removing the serialized sketches to one that works with bothprotofbuf
andjson
encodings.I also added an integration test, which identified a bug in
streamsForFieldDetection
that this PR also fixes.