Skip to content
Closed
6 changes: 6 additions & 0 deletions docs/changelog/125462.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
pr: 125462
summary: Assign new id to alias created by `ReplaceMissingFieldWithNull` when there
is lookup join
area: ES|QL
type: bug
issues: []
Original file line number Diff line number Diff line change
Expand Up @@ -986,6 +986,32 @@ public void testDoubleParamsWithLookupJoin() throws IOException {
);
}

public void testMultipleBatchesWithLookupJoin() throws IOException {
assumeTrue(
"Requires new null alias ids for join with multiple batches",
EsqlCapabilities.Cap.REPLACE_MISSING_FIELD_WITH_NULL_NEW_ALIAS_ID_FOR_JOIN_AND_MULTIPLE_BATCHES.isEnabled()
);
// Create more than 10 indices to trigger multiple batches of data node execution.
// The sort field should be missing on some indices to reproduce NullPointerException caused by duplicated items in layout
for (int i = 1; i <= 20; i++) {
createIndex("idx" + i, randomBoolean(), "\"mappings\": {\"properties\" : {\"a\" : {\"type\" : \"keyword\"}}}");
}
bulkLoadTestDataLookupMode(10);
// lookup join with and without sort
for (String sort : List.of("", "| sort integer")) {
var query = requestObjectBuilder().query(format(null, "from * | lookup join {} on integer {}", testIndexName(), sort));
Map<String, Object> result = runEsql(query);
var columns = as(result.get("columns"), List.class);
assertEquals(21, columns.size());
var values = as(result.get("values"), List.class);
assertEquals(10, values.size());
}
// clean up
for (int i = 1; i <= 20; i++) {
assertThat(deleteIndex("idx" + i).isAcknowledged(), is(true));
}
}

private void validateResultsOfDoubleParametersForIdentifiers(RequestObjectBuilder query) throws IOException {
Map<String, Object> result = runEsql(query);
Map<String, String> colA = Map.of("name", "boolean", "type", "boolean");
Expand Down Expand Up @@ -1668,6 +1694,13 @@ private static String repeatValueAsMV(Object value) {
return "[" + value + ", " + value + "]";
}

private static void createIndex(String indexName, boolean lookupMode, String mapping) throws IOException {
Request request = new Request("PUT", "/" + indexName);
String settings = "\"settings\" : {\"mode\" : \"lookup\"}, ";
request.setJsonEntity("{" + (lookupMode ? settings : "") + mapping + "}");
assertEquals(200, client().performRequest(request).getStatusLine().getStatusCode());
}

public static RequestObjectBuilder requestObjectBuilder() throws IOException {
return new RequestObjectBuilder();
}
Expand Down
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried the following, and it gives "no child with doc id found" in InsertFieldExtraction:

from *
| rename city.country.continent.planet.name as message
| lookup join message_types_lookup on message
| keep birth_date, language_code
| mv_expand birth_date
| sort language_code, birth_date
| limit 1
;

That's the diff from ReplaceMissingFieldWithNull:

Project[[birth_date{r}#868, language_code{f}#859]]                                                                       = Project[[birth_date{r}#868, language_code{f}#859]]
\_Limit[1[INTEGER],false]                                                                                                = \_Limit[1[INTEGER],false]
  \_OrderBy[[Order[language_code{f}#859,ASC,LAST], Order[birth_date{r}#868,ASC,LAST]]]                                   =   \_OrderBy[[Order[language_code{f}#859,ASC,LAST], Order[birth_date{r}#868,ASC,LAST]]]
    \_MvExpand[birth_date{f}#865,birth_date{r}#868]                                                                      =     \_MvExpand[birth_date{f}#865,birth_date{r}#868]
      \_EsqlProject[[birth_date{f}#865, language_code{f}#859]]                                                           !       \_Project[[birth_date{r}#881, language_code{f}#859]]
        \_Join[LEFT,[message{r}#851],[message{r}#851],[message{f}#867]]                                                  !         \_Eval[[null[DATETIME] AS birth_date]]
          |_EsqlProject[[birth_date{f}#865, city.country.continent.planet.name{f}#864 AS message, language_code{f}#859]] !           \_Join[LEFT,[message{r}#851],[message{r}#851],[message{f}#867]]
          | \_EsRelation[*][birth_date{f}#865, city.country.continent.planet.na..]                                       !             |_Project[[birth_date{r}#865, city.country.continent.planet.name{f}#864 AS message, language_code{f}#859]]
          \_EsRelation[message_types_lookup][LOOKUP][message{f}#867]                                                     !             | \_Eval[[null[DATETIME] AS birth_date]]
                                                                                                                         !             |   \_EsRelation[*][birth_date{f}#865, city.country.continent.planet.na..]
                                                                                                                         !             \_EsRelation[message_types_lookup][LOOKUP][message{f}#867]

Notice how MvExpand now references a missing attribute.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for reviewing @alex-spies!

Today, ReplaceMissingFieldWithNull only replace missing fields in Project, Eval, Filter, OrderBy, RegexExtract and TopN, it doesn't replace missing fields in the other commands like MvExpand. One option I can think of is whether covering more commands in this rule can solve this problem, I'll give it a try, if birth_date can be identified as a missing field for MvExpand, and if replacing it with a null alias works.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for catching this issue with MvExpand @alex-spies ! I added MvExpand in ReplaceMissingFieldWithNull, so that the missing field(target) referenced by MvExpand is replaced by null, expanded's id is kept unchanged, and also added some tests for MvExpand and Aggregation after lookup joins.

ReplaceMissingFieldWithNull does not replace missing fields in aggregations, however I haven't seen queries failed because of it yet, perhaps the downstream processes aggregations in a smarter way.

Another option to address #121754 is to remove duplicated entries(ChannelSet) in the layout, in case duplicated entries are expected or not avoidable, so that the DefaultLayout.inverse() does not create a null ChannelSet in the list.

Original file line number Diff line number Diff line change
Expand Up @@ -1452,3 +1452,20 @@ emp_no:integer | language_code:integer | language_name:keyword
10092 | 1 | English
10093 | 3 | Spanish
;

multipleBatches
required_capability: join_lookup_v12
required_capability: remove_redundant_sort
required_capability: replace_missing_field_with_null_new_alias_id_for_join_and_multiple_batches

from *
| rename city.country.continent.planet.name as message
| lookup join message_types_lookup on message
| sort language_code, birth_date
| keep birth_date
| limit 1
;

birth_date:date
null
;
Original file line number Diff line number Diff line change
Expand Up @@ -918,7 +918,12 @@ public enum Cap {
/**
* Index component selector syntax (my-data-stream-name::failures)
*/
INDEX_COMPONENT_SELECTORS(DataStream.isFailureStoreFeatureFlagEnabled());
INDEX_COMPONENT_SELECTORS(DataStream.isFailureStoreFeatureFlagEnabled()),

/**
* Create null alias with new id in ReplaceMissingFieldWithNull when there is lookup join with multiple batches.
*/
REPLACE_MISSING_FIELD_WITH_NULL_NEW_ALIAS_ID_FOR_JOIN_AND_MULTIPLE_BATCHES;

private final boolean enabled;

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -81,7 +81,11 @@ else if (plan instanceof Project project) {
Alias nullAlias = nullLiteral.get(f.dataType());
// save the first field as null (per datatype)
if (nullAlias == null) {
Alias alias = new Alias(f.source(), f.name(), Literal.of(f, null), f.id());
// In case of batch executions on data nodes and join exists, SearchStats may not always be available for all,
// fields, creating a new alias for null with the same id as the field id can potentially cause planEval to add a
// duplicated ChannelSet to a layout, and Layout.builder().build() could throw a NullPointerException.
// As a workaround, assign a new alias id to the null alias when join exists and SearchStats is not available.
Alias alias = new Alias(f.source(), f.name(), Literal.of(f, null), joinAttributes.isEmpty() ? f.id() : null);
Copy link
Contributor

@alex-spies alex-spies Mar 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot @fang-xing-esql for getting to the bottom of this!

I think this approach unfortunately still has problems. There could be downstream commands that still reference the old name id, but now the attribute with the old id is gone for good (projected away). For instance, there might be another LOOKUP JOIN command after the projection, or an MV_EXPAND, and I think this one will just break due to the name id being completely absent from the previous commands' layouts. The only subsequent commands that are OK to use downstream are those taken care of in the next else if branch below, namely Eval, Filter, OrderBy, RegexExtract and TopN.

I guess there are 2 approaches of eliminating missing fields: either, define a new attribute pointing to a null literal with an own id - and update all downstream references to point to the new attribute; OR update the attribute in place by defining a null literal with the same name id + make sure we never extract the original attribute in the first place; the latter is sketchy because, as we can see here, it can lead to re-defining the same name id multiple times.

Now, I think a part of the correct long-term solution is that we avoid the lookup join when the left hand side join key is missing. But that's not sufficient: I can see that we're introducing multiple Projects for the same missing attribute even if it is not a join key, like so (taken from your csv test):

Project[[birth_date{f}#15, language_code{f}#9]]
\_TopN[[Order[language_code{f}#9,ASC,LAST], Order[birth_date{f}#15,ASC,LAST]],1[INTEGER]]                      
  \_Join[LEFT,[message{r}#3],[message{r}#3],[message{f}#17]]                                                   
    |_EsqlProject[[birth_date{f}#15, city.country.continent.planet.name{f}#14 AS message, language_code{f}#9]]
    | \_EsRelation[*][birth_date{f}#15, city.country.continent.planet.nam..]                                   
    \_EsRelation[message_types_lookup][LOOKUP][message{f}#17]                                                  

The problem is that there are 2 Projects for birth_date, which is locally missing, and ReplaceMissingFieldWithNull will lead to the addition of the null attribute birth_date with the id 15 twice. Your fix gives that a new id each time, but if birth_date{f}#15 is used anywhere after the second Project (in a more complex query), it will be missing.

Therefore, I think the second, more crucial, part of a correct solution is that we avoid replacing attributes by other attributes with the same name id, at all. Instead, I think we should update ReplaceMissingFieldWithNull so that it always assigns new ids - and updates any downstream references to the missing field attribute with a reference attribute to the newly defined null attribute.

nullLiteral.put(dt, alias);
projection = alias.toAttribute();
}
Expand Down
Loading