Handle failed request when auto create index is disabled

[markharwood]

If a bulk request contains a mix of indexing requests for an existing index and one that needs to be auto-created but a cluster configuration prevents the auto-create of the new index, the ingest process hangs. The exception for the failure to create an index was not caught or reported back properly. Added a Junit test to recreate the issue and the associated fix is in TransportBulkAction.

Closes #8125

[bleskes]

I think adding an explicit handling of IndexMissingException which will not cause the entire request to fail. However, the source of the problem is deeper and lies in the fact that we don't deal with failure correctly in the executeBulk method while returning from the create index command. IMHO this is where the proper fix belongs.

[markharwood]

@bleskes can you review the last change please? thx

[bleskes]

I think we simplify this code by merging the two use cases. The only difference is the exception that goes into the BulkItemResponse.Failure object. Can we have that as a variable instead of isClosed , i.e., Exception unavailableException = null and later check:

 if (unavailableException != null) {
             BulkItemResponse.Failure failure = new BulkItemResponse.Failure(request.index(), request.type(), request.id(), unavailableException);
             BulkItemResponse bulkItemResponse = new BulkItemResponse(idx, "index", failure);
             responses.set(idx, bulkItemResponse);
             // make sure the request gets never processed again
             bulkRequest.requests.set(idx, null);
         }

[bleskes]

@markharwood I left one more comment, once that's done I think it's good.

[markharwood]

Rebased and consolidated exception handling

[bleskes]

LGTM. Thx @markharwood

[markharwood]

@bleskes Pushed to master, 1.x and 1.4 but TransportBulkAction in 1.3 looks different and is missing addFailureIfIndexIsClosed() method.
Are we back-porting this fix and the related checks for closed indexes into 1.3?

[bleskes]

@markharwood thx. I think this an important bug fix. It can go into 1.3 as well.

[markharwood]

@bleskes @GaelTadh 1.3 is missing 61c21f9a which addresses #6410
My patch here extends the above's logic for testing for closed indices - any reason that didn't go into 1.3, Brian?

[clintongormley]

@markharwood @GaelTadh I think #6410 should go into 1.3 as well

[GaelTadh]

Looks like both 61c21f9 and this depend on 5d987ad.

[GaelTadh]

5d987ad addresses #7223, this is a fairly big change that is only in 1.4B1 and up.

[clintongormley]

OK - then let's merge this only into 1.4. thanks @GaelTadh

[s1monw]

from the history here this seems to be committed to 1.4 and up, can we close it?

[markharwood]

Committed to 1.4 and up, see d12ae19