Skip to content

BulkAsync ignores request-level index setting #8522

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

Open
jonyadamit opened this issue May 11, 2025 · 1 comment
Open

BulkAsync ignores request-level index setting #8522

jonyadamit opened this issue May 11, 2025 · 1 comment
Labels

Comments

@jonyadamit
Copy link
Contributor

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):

@jonyadamit jonyadamit added Category: Bug 9.x Relates to a 9.x client version labels May 11, 2025
@flobernd
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants