BulkAsync ignores request-level index setting

[jonyadamit]

Elastic.Clients.Elasticsearch version: 9.0.3

Elasticsearch version: 9.0.1

.NET runtime version: 9

Operating system version: Windows Server 2019 Standard

Description of the problem including expected versus actual behavior:
Calling client.BulkAsync(b => b.Index("someindex").IndexMany<T>(entities) fails with:

Index name is null for the given type and no default index is set. Map an index name using ConnectionSettings.DefaultMappingFor() or set a default index using ConnectionSettings.DefaultIndex()

As a workaround, I now need to call client.BulkAsync(b => b.IndexMany(entities, (e, x) => e.Index(indexName))

Moreover, this happens even though a default mapping does exist for the type, so this bug might be two-fold.

Steps to reproduce:

1. Call BulkAsync with an index name in BulkRequestDescriptor, but without index name in BulkIndexOperationDescriptor.

Expected behavior
The bulk index should take the index name from the request if specified.

Provide ConnectionSettings (if relevant):

Provide DebugInformation (if relevant):

[flobernd]

Hi @jonyadamit,

Uh, this is a confusing one. The call to b.Index(string) does not set a global index for the bulk operations in this case, but instead adds an operation that tries to index a document with content "someindex". It's basically referring to the "single" document version of IndexMany().

This is counter intuitive and I try to improve this so that the IndexName overload is preferred for string values. In the meantime, you could try this workaround:

b.Index((IndexName)"someindex")

Moreover, this happens even though a default mapping does exist for the type, so this bug might be two-fold.

You are right. This part requires a refactoring to make sure that all combinations (global index, per-operation index) are working fine without changing the current behavior in any undesired ways.

[flobernd]

@jonyadamit

Moreover, this happens even though a default mapping does exist for the type, so this bug might be two-fold.

The latest 8.9.x and 9.3.x versions contain a fix for the ignored default mapping. The method name ambiguity is still not addressed.