Enable querier execution from logical plan #6908
Conversation
fe31a41 to
2f83e12
Compare
|
An open question: when we expect to execute from a logical plan but receive an empty plan parameter, should we My current implementation does the fallback, but I'm wondering if this masks potential frontend issues we should catch instead |
2f83e12 to
422b1f2
Compare
Signed-off-by: rubywtl <rubyharrisonlee@gmail.com>
Signed-off-by: rubywtl <rubyharrisonlee@gmail.com>
Signed-off-by: rubywtl <rubyharrisonlee@gmail.com>
Signed-off-by: rubywtl <rubyharrisonlee@gmail.com>
…ler code Signed-off-by: rubywtl <rubyharrisonlee@gmail.com>
Signed-off-by: rubywtl <rubyharrisonlee@gmail.com>
a7a4faf to
d984196
Compare
Signed-off-by: rubywtl <rubyharrisonlee@gmail.com>
Signed-off-by: rubywtl <rubyharrisonlee@gmail.com>
| endTime := convertMsToTime(end) | ||
| stepDuration := convertMsToDuration(step) | ||
|
|
||
| byteLP := []byte(r.PostFormValue("plan")) |
There was a problem hiding this comment.
Can we use FormValue to align with how we parse other parameters?
| } | ||
| qry, err = q.queryEngine.MakeInstantQueryFromPlan(ctx, q.queryable, opts, logicalPlan, tsTime, r.FormValue("query")) | ||
| if err != nil { | ||
| return apiFuncResult{nil, &apiError{errorBadData, fmt.Errorf("failed to create range query from logical plan: %v", err)}, nil, nil} |
| if len(byteLP) != 0 { | ||
| logicalPlan, err := logicalplan.Unmarshal(byteLP) | ||
| if err != nil { | ||
| return apiFuncResult{nil, &apiError{errorBadData, fmt.Errorf("invalid logical plan: %v", err)}, nil, nil} |
There was a problem hiding this comment.
Bad data error is a 400 and usually means something wrong on the user request. This seems ok if querier is directly queried by the user and plan is provided there. But in this usecase, we expect the plan provided by the Query Frontend.
If a plan is able to be generated and sent to Querier, it should eliminate the case of bad request. To me, unable to deserialize the created plan seems a service issue rather than a client issue under this scenario as the generated plan might be wrong. Returning 4XX in this case might make users confusing.
Let's see what others think.
What this PR does:
This PR enables the queriers to execute a logical plan derived from the serialized logical plan in the request body, under the distributed execution feature flag. It includes a fallback to the PromQL engine when necessary.
Unit tests have been added to verify that queries are correctly executed from the logical plan in the request body when expected, as opposed to the query string in the request URL
Which issue(s) this PR fixes:
Addresses the problem outlined in proposal 6789
Checklist
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX]