Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

_source not returned in "explain": true with certain queries #31000

Closed
nerophon opened this issue May 31, 2018 · 5 comments · Fixed by #60179
Closed

_source not returned in "explain": true with certain queries #31000

nerophon opened this issue May 31, 2018 · 5 comments · Fixed by #60179
Assignees
Labels
>bug :Search/Search Search-related issues that do not fall into other categories Team:Search Meta label for search team

Comments

@nerophon
Copy link

Elasticsearch version: 5.9.6 & 6.2.4

Plugins installed: []

JVM version: independent

OS version: independent

Description of the problem including expected versus actual behavior:
The _source is not being returned for hits when explain is set to true for a specific set of queries. The conditions for _source to be missing appear to be:

  • A mapping with a nested field
  • A document with that nested field populated
  • A query which:
    • Matches that document
    • Has explain set to true
    • Uses rescore, with a nested function_score query matching the nested field
    • Adjusts the score using script_score

Steps to reproduce:

PUT /test
{
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 1
  },
  "mappings": {
    "type1": {
      "properties": {
        "object1": {
          "type": "nested",
          "properties": {
            "field1": {
              "type": "text"
            }
          }
        }
      }
    }
  }
}
PUT /test/type1/1
{
  "object1": {
    "field1": "some text goes here"
  }
}
GET /test/_search
{
  "from" : 0,
  "size" : 10,
  "query" : {
    "match_all": { }
  },
  "explain" : true,
  "rescore" : [
    {
      "window_size" : 200,
      "query" : {
        "rescore_query" : {
          "nested" : {
            "query" : {
              "function_score" : {
                "query" : {
                  "match_all": { }
                },
                "functions" : [
                  {
                    "script_score" : {
                      "script" : {
                        "source" : "1",
                        "lang" : "painless"
                      }
                    }
                  }
                ],
                "score_mode" : "multiply"
              }
            },
            "path" : "object1"
          }
        },
        "query_weight" : 1.0,
        "rescore_query_weight" : 1.0,
        "score_mode" : "total"
      }
    }
  ]
}
@nerophon nerophon added >bug :Search/Search Search-related issues that do not fall into other categories labels May 31, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search-aggs

@javanna
Copy link
Member

javanna commented Nov 11, 2019

I finally got to doing some digging on this one. Indeed, it is a very peculiar bug, and I am not sure yet how to solve it, but I can now explain how it happens: this only happens when explaining a script score function that's part of a nested query inside a rescore section.

When trying to explain the score function, we run the script which ends up calling LeafSearchLookup#setDocument which calls SourceLookup#setSegmentAndDocument that ends up zeroing the source that was previously loaded, as we are going through a different docId compared to the previous run (nested doc rather than parent doc).

@rjernst rjernst added the Team:Search Meta label for search team label May 4, 2020
@fhaase2
Copy link

fhaase2 commented Jul 16, 2020

@javanna do you have a suggestion how to make it still working? Is there some hack?

@jtibshirani
Copy link
Contributor

jtibshirani commented Jul 27, 2020

@fhaase2 unfortunately I can't think of a workaround that doesn't change meaning of the request. If you could rework the request to remove the 'script score' part, that would avoid this issue.

I just opened a refactor #60179 that would fix this issue properly.

@fhaase2
Copy link

fhaase2 commented Jul 27, 2020

@jtibshirani great, thanks for the answer.

As a workaround i thought about making a subsequent request after the explain request, just to retrieve the source of the documents using the Ids query. But this would be a hack, so ill better wait for the refactor #60179

jtibshirani added a commit that referenced this issue Jul 30, 2020
The `SourceLookup` class provides access to the _source for a particular
document, specified through `SourceLookup#setSegmentAndDocument`. Previously
the search context contained a single `SourceLookup` that was shared between
different fetch subphases. It was hard to reason about its state: is
`SourceLookup` set to the expected document? Is the _source already loaded and
available?

Instead of using a global source lookup, the fetch hit context now provides
access to a lookup that is set to load from the hit document.

This refactor closes #31000, since the same `SourceLookup` is no longer shared
between the 'fetch _source phase' and script execution.
jtibshirani added a commit that referenced this issue Jul 30, 2020
The `SourceLookup` class provides access to the _source for a particular
document, specified through `SourceLookup#setSegmentAndDocument`. Previously
the search context contained a single `SourceLookup` that was shared between
different fetch subphases. It was hard to reason about its state: is
`SourceLookup` set to the expected document? Is the _source already loaded and
available?

Instead of using a global source lookup, the fetch hit context now provides
access to a lookup that is set to load from the hit document.

This refactor closes #31000, since the same `SourceLookup` is no longer shared
between the 'fetch _source phase' and script execution.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Search/Search Search-related issues that do not fall into other categories Team:Search Meta label for search team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants