Inconsistent behavior of ignoreUnavailable on closed Indices

[JD557]

Elasticsearch version: 2.3.4

JVM version: 1.8.0_66

OS version: Tested on the official elasticsearch docker image and on Mac OS X 10.11.6

Description of the problem including expected versus actual behavior:

Executing a search query to a closed index with the ignoreUnavailable flag set to true works via the HTTP interface, yet it fails if the request is done via the Java API (it seems to work as expected for non-existent indices).

Steps to reproduce:

1. Create an index in elasticsearch
2. Close that index
3. Attempt to access it via HTTP (http://<host>:<port>/closed_index/_search?ignore_unavailable). The request will be successful.
4. Attempt to access it via the Java API (setting the unavailable ignore flag using IndicesOptions.fromOptions(true, true, true, false) or IndicesOptions.lenientExpandOpen()). The request will fail with a [FORBIDDEN/4/index closed].

[javanna]

Hi @JD557 sorry it has taken a while to get back to you on this but can you please share your java api code?

[JD557]

I don't really have a Java API code (I use a elastic4s, which is a Java API wrapper).

Nevertheless, here's my scala specs2 test that I used to reproduce this problem:

"silently ignore failures" in {
  val f = for {
    _ <- client.execute(index into "deleted-index" -> "t" fields ("test" -> "deleted"))
    _ <- client.execute(index into "closed-index" -> "t" fields ("test" -> "closed"))
    _ <- client.execute(index into "open-index" -> "t" fields ("test" -> "open"))
    _ <- client.execute(delete index "deleted-index")
    ff <- client.execute(close index "closed-index")
  } yield ff

  Await.result(f, 60.seconds) // Hackish way to make sure that everything was executed

  val ignoreUnavailable = IndicesOptions.fromOptions(
    true, // ignoreUnavailable
    true, // allowNoIndices
    true, // expandToOpenIndices
    false // expandToClosedIndices
  )

  // Make sure that closed indices are not forbidden
  ignoreUnavailable.forbidClosedIndices() === false 

  // Normal queries should fail on unknown, deleted and closed indices
  client.execute(search in "unknown-index" -> "t") must throwAn[Exception].await // PASS
  client.execute(search in "deleted-index" -> "t") must throwAn[Exception].await // PASS
  client.execute(search in "closed-index" -> "t") must throwAn[Exception].await // PASS


  // Normal queries should fail on unknown, deleted and closed indices
  client.execute(search in "open-index" -> "t") must not(throwAn[Exception]).await // PASS


  // Queries with custom flags should succeed on unknown, deleted and closed indices
  client.execute(search in "unknown-index" -> "t" indicesOptions ignoreUnavailable) must not(throwAn[Exception]).await // PASS
  client.execute(search in "deleted-index" -> "t" indicesOptions ignoreUnavailable) must not(throwAn[Exception]).await // PASS
  client.execute(search in "closed-index" -> "t" indicesOptions ignoreUnavailable) must not(throwAn[Exception]).await // FAIL
}

[javanna]

heya @JD557 the problem is caused by setting forbidClosedIndices to false. That is an internal option, that is not exposed through REST and should be left to true for search, as search cannot execute, like many other apis, against closed indices. If you don't ignore unavailable indices, then you get back an IndexClosedException (better than the cluster block you are seeing), otherwise we just ignore the closed indices. Setting forbid closed indices to false causes the search api to try and execute against closed indices which hits a wall just a bit later on, the error that you got. I hope this clarifies things for you.

[JD557]

Thanks for your response.

I think that either you misunderstood my post or I misunderstood yours: Are you saying that there's no way to get the same behavior using the Java API? Can I only either get an Exception or a cluster block?

If that's not the case (and it's possible to perform a query equivalent to the REST API), then I need to ask another question:

heya @JD557 the problem is caused by setting forbidClosedIndices to false.

Just to make things clear, I'm not setting it to false: The === operator is a shorthand for an equality assertion (I'm not sure if this was clear in my example).

As you might be aware, it's "impossible" to set the value of forbidClosedIndices directly. I believe that all methods that change that value are private, as you can see in IndicesOptions.java, so my only choice is to pick one of the predefined sets of indices options.

So, to get a query equivalent to the REST API, which predefined IndicesOptions do I need to pick?

[javanna]

You are right, I didn't notice that you weren't setting forbidClosedIndices yourself. This is quite odd. This is how you can work around this issue: IndicesOptions.fromOptions(true, true, true, false, SearchRequest.DEFAULT_INDICES_OPTIONS). This way only the flags that you pass in will be changed, the others will come from the default for a search request that has forbidClosedIndices set to true.

We are planning to revisit the indices options as they expose some internal bits to the Java API which is not desirable. See #9438. We will take this into account for sure.