Fix UnresolvedException on PromQL by(step) grouping#145307
Fix UnresolvedException on PromQL by(step) grouping#145307felixbarny merged 1 commit intoelastic:mainfrom
Conversation
Guard AcrossSeriesAggregate.output() against calling dataType() on unresolved attributes, which threw UnresolvedException during optimization. Reject PromQL by(step) groupings in postAnalysisVerification because the label name "step" collides with the built-in step time bucket output column. A future improvement could add an option to rename the built-in step column to support this. Also make STEP_COLUMN_NAME private and use stepColumnName() accessor throughout.
|
Pinging @elastic/es-storage-engine (Team:StorageEngine) |
| "PROMQL index=k8s step=1m result=(sum by (step) (network.eth0.rx))", | ||
| "PROMQL index=k8s step=1m result=(sum by (step, pod) (network.eth0.rx))" | ||
| )) { | ||
| var e = expectThrows(VerificationException.class, () -> planPromql(query)); |
There was a problem hiding this comment.
Is this converted to 4xx or 5xx? Can't recall where the mapping is defined.
There was a problem hiding this comment.
Validation errors are always client errors (4xx).
| failures.add( | ||
| fail( | ||
| agg, | ||
| "label [{}] collides with the built-in [{}] output column [{}]", |
There was a problem hiding this comment.
This is fine as a stopgap, but I wonder if we can differentiate between the two. Maybe we can implicitly add an alias to the label, to avoid the conflict?
There was a problem hiding this comment.
Maybe we can implicitly add an alias to the label, to avoid the conflict?
What do you have in mind there? That'll still change the name of the output column, so I'm not sure if that'll work.
…rics * upstream/main: (428 commits) ESQL: DS: Add inference/RERANK tests (elastic#145229) Unmute MMR logical plan test (elastic#145311) Do not attempt marking store as corrupted if the check is rejected due to shutdown (elastic#145209) feat(tsdb): add pipeline runtime and rename stage interfaces (elastic#145175) Fix UnresolvedException on PromQL by(step) grouping (elastic#145307) ES|QL: Optimize MMR by reducing cache size and lookup (elastic#145014) Prometheus labels/series APIs: support multiple match[] selectors (elastic#145298) Move ClientScrollablePaginatedHitSource into Reindex Module (elastic#144100) mute test class for elastic#145277 CPS mode for ViewResolver (elastic#145219) [ESQL] Disables GroupedTopNBenchmark temporarily (elastic#145124) Make exponential_histogram the default histogram type for HTTP OTLP endpoint (elastic#145065) More tests requiring an explicit confidence interval (elastic#145232) ES|QL: Adding `USER_AGENT` command (elastic#144384) ESQL: enable Generative IT after more fixes (elastic#145112) Rework FieldMapper parameter tests to not use merge builders (elastic#145213) [ESQL] Fix ORC type support gaps (elastic#145074) [Test] Unmute FollowingEngineTests.testProcessOnceOnPrimary (elastic#145192) Add PrometheusSeriesRestAction for /_prometheus/api/v1/series endpoint (elastic#144494) Prometheus labels API: add rest action (elastic#144952) ...
Guard AcrossSeriesAggregate.output() against calling dataType() on unresolved attributes, which threw UnresolvedException during optimization. Reject PromQL by(step) groupings in postAnalysisVerification because the label name "step" collides with the built-in step time bucket output column. A future improvement could add an option to rename the built-in step column to support this. Also make STEP_COLUMN_NAME private and use stepColumnName() accessor throughout.
| return List.of(timeseriesAttribute); | ||
| } | ||
| return groupings.stream().filter(not(a -> a.dataType() == DataType.NULL)).toList(); | ||
| return groupings.stream().filter(a -> a.resolved() == false || a.dataType() != DataType.NULL).toList(); |
There was a problem hiding this comment.
@felixbarny , I know this is already merged, but this doesn't look right. Unresolved attributes must not be present when output is called.
The javadoc for the output method states:
* Must be called only on resolved plans, otherwise may throw an exception or return wrong results.
There was a problem hiding this comment.
This wasn't the primary fix but a defensive check. Maybe too defensive in this case...
Maybe better to fail early or add something like an assert resolved() here.
…gregate Encodes the contract from QueryPlan#output() with an assert rather than silently accepting unresolved attributes in the output stream. Relates: elastic#145307
…gregate (elastic#145525) Encodes the contract from QueryPlan#output() with an assert rather than silently accepting unresolved attributes in the output stream. Relates: elastic#145307
Fixes an
UnresolvedException: Invalid call to dataType on an unresolved object ?stepseen on serverless when a PromQL query groups by a label namedstep, which collides with the built-insteptime bucket output column.AcrossSeriesAggregate.output()against callingdataType()on unresolved attributesby(step)groupings inpostAnalysisVerificationwith a clear error message, since the label name collides with the built-in step columnSTEP_COLUMN_NAMEprivate and usestepColumnName()accessor throughout