Search over non-existent index name with wildcard returns incorrect scroll_id

[gregolsen]

Elasticsearch Version

7.17.1

Installed Plugins

No response

Java Version

bundled

OS Version

Problem Description

On 7.17.0 running a search query where index name is a wildcard that doesn't match any indices returns payload without scroll_id:

GET /non_existent*/_search?scroll=1m&size=10

{
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 0,
    "successful" : 0,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 0,
      "relation" : "eq"
    },
    "max_score" : 0.0,
    "hits" : [ ]
  }
}

On 7.17.1 running the same query returns scroll_id:

GET /non_existent*/_search?scroll=1m&size=10

{
  "_scroll_id" : "FGluY2x1ZGVfY29udGV4dF91dWlkDnF1ZXJ5VGhlbkZldGNoAA==",
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 0,
    "successful" : 0,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 0,
      "relation" : "eq"
    },
    "max_score" : 0.0,
    "hits" : [ ]
  }
}

Returning scroll_id is misleading – if the client attempts to fetch next page exception is thrown:

GET /_search/scroll?scroll_id=FGluY2x1ZGVfY29udGV4dF91dWlkDnF1ZXJ5VGhlbkZldGNoAA==

{
  "error" : {
    "root_cause" : [ ],
    "type" : "search_phase_execution_exception",
    "reason" : "no nodes to search on",
    "phase" : "query",
    "grouped" : true,
    "failed_shards" : [ ]
  },
  "status" : 503
}

This scroll_id is always the same. Its decoded value is \x14include_context_uuid\x0EqueryThenFetch\x00 – just the header of the real scroll id. But there's no shards to search over – hence the exception on fetching the next page.

Steps to Reproduce

Running GET /non_existent*/_search?scroll=1m&size=10 should not return scroll_id as part of the payload as it was in 7.17.0.

Logs (if relevant)

No response

[dnhatn]

This is related to #83424.

[elasticmachine]

Pinging @elastic/es-search (Team:Search)

[javanna]

@dnhatn does this mean that what is described is now the expected behaviour? Any follow-up needed or can we close this issue?

[benwtrent]

This is expected