Migrating from Elastic NEST v7 to .NET Elastic Client v8: Index alias search

Elastic Stack Elasticsearch
1

while migrating .net package from NEST to Elastic.Clients.Elasticsearch. Observed one issue of double search indexes if they have the same alias.

We have a time rollover index created once a week. every week, there will be a new index created with new date. (new index is in hot phase and old index moves to cold phase staying for a week). but both index will have the same alias name.

When used the NEST package, the query always hit the latest index and return the proper count and aggregation buckets.
after migrating to the new ES .net package, the same query returns double count. (old + new)
Confirming it by manually deleting old index, the query returns correct match count).

Any suggestions for this issue?

2

Hi @zoey_L , do you use DefaultIndex or type-to-index mappings with the new client?

I assume the issue happens with the Search() endpoint?

Could you please try to explicitly set Indices("my_index") for this call and test again?

3

hi @flobernd thank you for the reply! yes! I was using DefaultIndex in the client setting:
```
var settings = new ElasticsearchClientSettings(new Uri(url))
.DefaultIndex(defaultIndex)
.EnableDebugMode()
.Authentication(new BasicAuthentication(username, password));
```
I tested with your suggestions by using .Indices() in the query and it works! can you explain the issue more? and is there any alternative way to use DefaultIndex config to fix the issue rather than explicitly passing index names in all queries?

4

Hi @zoey_L , yes this is tracked in this issue:

There was a breaking change in the behavior of APIs that accepts multiple indices. In NEST, DefaultIndex would override the default behavior (which is to query all indices) to just use the single DefaultIndex.

In the new client, this is no longer the case (only for APIs that accept a single index).

Since this seems to be confusing, I might revert that new behavior, but a final decision hasn’t been made so far.

5

Thanks for sharing this helpful info. It helps a lot. I believe the workaround for now is explicitly adding all index name in all queries. But if it can improve in the future, it helps a lot. I will let the teams know this breaking changes.