FIX: UOE While building Exists query for nested search_as_you_type field

[Luci-MG]

Description

FIX: Fixes UOE while building exists query for nested search_as_you_type field

Related Issues

Resolves #11821

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)
• Commits are signed per the DCO using --signoff
• Commit changes are listed out in CHANGELOG.md file (See: Changelog)
• Public documentation issue/PR created

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Signed-off-by: Mrudhul Guda [email protected]

[github-actions]

❌ Gradle check result for 24ef688: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❌ Gradle check result for 8ba8994: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

Compatibility status:

Checks if related components are compatible with change e0a9a08

Incompatible components

Incompatible components: [https://github.com/opensearch-project/security-analytics.git]

Skipped components

Compatible components

Compatible components: [https://github.com/opensearch-project/custom-codecs.git, https://github.com/opensearch-project/flow-framework.git, https://github.com/opensearch-project/job-scheduler.git, https://github.com/opensearch-project/observability.git, https://github.com/opensearch-project/cross-cluster-replication.git, https://github.com/opensearch-project/geospatial.git, https://github.com/opensearch-project/opensearch-oci-object-storage.git, https://github.com/opensearch-project/k-nn.git, https://github.com/opensearch-project/sql.git, https://github.com/opensearch-project/neural-search.git, https://github.com/opensearch-project/asynchronous-search.git, https://github.com/opensearch-project/reporting.git, https://github.com/opensearch-project/ml-commons.git, https://github.com/opensearch-project/notifications.git, https://github.com/opensearch-project/common-utils.git, https://github.com/opensearch-project/index-management.git, https://github.com/opensearch-project/anomaly-detection.git, https://github.com/opensearch-project/performance-analyzer-rca.git, https://github.com/opensearch-project/security.git, https://github.com/opensearch-project/alerting.git, https://github.com/opensearch-project/performance-analyzer.git]

[github-actions]

❌ Gradle check result for 0ff598a: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

❕ Gradle check result for 11b3b18: UNSTABLE

• TEST FAILURES:

      1 org.opensearch.search.SearchWeightedRoutingIT.testStrictWeightedRoutingWithCustomString_FailOpenEnabled
      1 org.opensearch.remotestore.RemoteIndexPrimaryRelocationIT.testPrimaryRelocationWhileIndexing

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

[msfroh]

LGTM! @msfroh can you take another look? Thanks

The change looks nice and simple.

I'm trying to figure out why the existsQuery threw an exception. What I've been able to piece together is that the SearchAsYouTypeFieldMapper was added in 2019, while the base existsQuery implementation was added in 2020. So that probably explains it.

Then I'm thinking, what path will this existsQuery take now? AFAIK, it will never match anything, looking at the super-class implementation:

        if (hasDocValues()) {
            return new DocValuesFieldExistsQuery(name());
        } else if (getTextSearchInfo().hasNorms()) {
            return new NormsFieldExistsQuery(name());
        } else {
            return new TermQuery(new Term(FieldNamesFieldMapper.NAME, name()));
        }

The prefix field doesn't have doc values or norms, so it will go into that third path. I could be mistaken, but I think <field_name>._index_prefix (the name of the prefix field) doesn't get added to the field names field, because it's not a "real" field.

I could be mistaken, but we might as well just return MatchNoDocsQuery?

[msfroh]

I think to me, the bigger question is why do we end up trying to call existsQuery on the prefix field type? I think there's a flaw in the logic somewhere else and the UOE is just highlighting that.

[msfroh]

I think to me, the bigger question is why do we end up trying to call existsQuery on the prefix field type? I think there's a flaw in the logic somewhere else and the UOE is just highlighting that.

Okay -- I was able to answer that by debugging the unit test that you added. (Thank you very much for that, by the way!)

I now understand that the issue comes from the outer object field (named field). Because it does not exist in the mapper service as a direct type, it tries iterating through all fields whose name starts with field.*, which includes the "virtual" fields, like the prefix and shingle fields. So far as I can tell, we would run into the same problem with a text field with index_prefixes enabled.

I tried the following change to newObjectFieldExistsQuery to avoid generating queries for those "virtual" subfields:

   private static Query newObjectFieldExistsQuery(QueryShardContext context, String objField) {
       BooleanQuery.Builder booleanQuery = new BooleanQuery.Builder();
       Collection<String> fields = context.simpleMatchToIndexNames(objField + ".*");
       for (String field : fields) {
           int dotPos = field.lastIndexOf('.');
           if (dotPos > 0 && field.charAt(dotPos + 1) == '_') { // This is a subfield (e.g. prefix) of a complex field type. Skip it.
               continue;
           }
           Query existsQuery = context.getMapperService().fieldType(field).existsQuery(context);
           booleanQuery.add(existsQuery, Occur.SHOULD);
       }
       return new ConstantScoreQuery(booleanQuery.build());
   }

[opensearch-trigger-bot]

This PR is stalled because it has been open for 30 days with no activity.

[msfroh]

@Luci-MG -- are you able to fix newObjectFieldExistsQuery instead? It looks like that's where the bug really resides.

[Luci-MG]

@Luci-MG -- are you able to fix newObjectFieldExistsQuery instead? It looks like that's where the bug really resides.

Hello @msfroh let me check that will update you

[Luci-MG]

Hello @msfroh as you stated we can skip query generation for virtual sub-fields so made the changes accordingly

1. In newObjectFieldExistsQuery skipped query generation by checking the virtual sub-fields
2. Modified expected case in the test case to skip virtual sub-fields like (_2gram, _3gram ...)
3. Re-Added throwing unsupportedexception for exists query (shall I remove it ?)

please review the changes and let me know if I need to make any additional changes

sorry for stalling MR was in the assumption that you have taken up the change for newObjectFieldExistsQuery

[github-actions]

❌ Gradle check result for fa4264a: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

[github-actions]

✅ Gradle check result for e0a9a08: SUCCESS

[opensearch-trigger-bot]

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-2.x
# Create a new branch
git switch --create backport/backport-12048-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 37569bad2665f0455fea39d6efc8f852bcab7cce
# Push it to GitHub
git push --set-upstream origin backport/backport-12048-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-12048-to-2.x.