ESQL's design philosophy has been to avoid failing queries on errors as much as possible. Scalars achieve this by trapping (expected) errors and setting their value to null for that row, with a warning. Aggregations, however, do not currently do this. Supporting null + warning for aggs has several steps:
That last step will require a change to the Layout. We currently have no capacity for evolving the Layout, which must be the same for all nodes participating in the query. Solving that will likely be the bulk of the work in this ticket.
ESQL's design philosophy has been to avoid failing queries on errors as much as possible. Scalars achieve this by trapping (expected) errors and setting their value to null for that row, with a warning. Aggregations, however, do not currently do this. Supporting null + warning for aggs has several steps:
SourceandWarningsobjects accessible from within the generated aggregations code@Aggregatorannotation to include a list of exceptions that should be turned into warnings, similar towarnExceptionson the@Evaluatorannotation, and update the code generation to catch those warnings in the appropriate placeThat last step will require a change to the Layout. We currently have no capacity for evolving the Layout, which must be the same for all nodes participating in the query. Solving that will likely be the bulk of the work in this ticket.