Today every driver failure that bails with RuntimeException will emit an error log line:
|
LOGGER.error(Strings.format("Error running driver [%s]", shortDescription), e); |
It seems that conditions other than "strictly" errors fall into this category - e.g. we often see cancelled by user as one of the messages, probably other conditions that result from user actions and parameters that are not strictly failures.
Ideally we want to make sure that anything that corresponds to a cancelled query or any 4xx condition doesn't generate this noise - warnings or infos would probably be fine here.
At the very least, catching the TaskCancelledException would go a long way.
Over 80% of errors we see for ES|QL in serverless are due to the user cancelations - this is quite a but of noise
Today every driver failure that bails with
RuntimeExceptionwill emit an error log line:elasticsearch/x-pack/plugin/esql/compute/src/main/java/org/elasticsearch/compute/operator/Driver.java
Line 196 in 263c178
It seems that conditions other than "strictly" errors fall into this category - e.g. we often see
cancelled by useras one of the messages, probably other conditions that result from user actions and parameters that are not strictly failures.Ideally we want to make sure that anything that corresponds to a cancelled query or any 4xx condition doesn't generate this noise - warnings or infos would probably be fine here.
At the very least, catching the
TaskCancelledExceptionwould go a long way.Over 80% of errors we see for ES|QL in serverless are due to the user cancelations - this is quite a but of noise