Elasticsearch-net: Nest 7.6 -> GetManyAsync methos -> throw UnexpectedElasticsearchClientException

[meriturva]

Using latest version 7.6 we have few problems on tests that use GetManyAsync call.

For example:
var response = await this.Context.Client.GetManyAsync<TEntity>(ids, this.IndexName);

Just generate exception:

 Elasticsearch.Net.UnexpectedElasticsearchClientException : Index name is null for the given type and no default index is set. Map an index name using ConnectionSettings.DefaultMappingFor<TDocument>() or set a default index using ConnectionSettings.DefaultIndex().
    ---- System.ArgumentException : Index name is null for the given type and no default index is set. Map an index name using ConnectionSettings.DefaultMappingFor<TDocument>() or set a default index using ConnectionSettings.DefaultIndex().
  Stack Trace: 
    Transport`1.RequestAsync[TResponse](HttpMethod method, String path, CancellationToken cancellationToken, PostData data, IRequestParameters requestParameters) line 149
    GetManyExtensions.GetManyAsync[T](IElasticClient client, IEnumerable`1 ids, IndexName index, CancellationToken cancellationToken) line 68

Actually I could give you a more precise reproduction of the problem but not in a short time.
Tell me if necessary.

Ps: i reverted version to 7.5.1 and tests pass again.

[Mpdreamz]

Can reproduce this as well, will get a fix up shortly

[Mpdreamz]

@meriturva this should be fixed as per #4463

Are you able to give the following canary build a try?

NEST.7.6.0-ci20200226T122106

From this nuget feed:

https://ci.appveyor.com/nuget/elasticsearch-net

Thanks a ton for reporting this!

[meriturva]

Thanks @Md right now I'm not able to change CI pipeline to include new feed source and really no time to test it locally (big project here).
If it is really necessary I will try tomorrow!

[Mpdreamz]

Not necessary :), was just curious if you could give it a quick spin.

We'll release new versions soon to nuget.org

[TheFireCookie]

I'm encountering the same bug. I'm glad it has already been corrected. When is a bugfix version planned to work? It prevents me to update to the latest, sweetest version for now.

[codebrain]

This fix will be going into 7.6.1 and 6.8.5

[TheFireCookie]

Hello @codebrain & @Mpdreamz , I've tried to update to 7.6.1 but it does not fix the issue for me.

Here is the code that I do to reproduce it:
var esResponse = await elasticClient.MultiGetAsync(m => m.Index(_fullIndexName).GetMany<EsSdMetadataProfile>(fqns));

Do you need somethings else? Here is the exception I have:
System.ArgumentException: 'Index name is null for the given type and no default index is set. Map an index name using ConnectionSettings.DefaultMappingFor<TDocument>() or set a default index using ConnectionSettings.DefaultIndex().'
Here is the callstack

[meriturva]

On my side it is fixed with 7.6.1 using: Client.GetManyAsync<TEntity>(ids, this.IndexName);

[TheFireCookie]

I could try to do that. So what would you recommend @codebrain & @Mpdreamz what's the best way to multi get documents with a specify index name?
MultiGet with a get many inside (like I this in my example), or calling directly the GetManyAsync at the root level?

[Mpdreamz]

@TheFireCookie thanks for raising this can confirm the fix does not apply to MultiGet and the workaround @meriturva listed should work in 7.6.1 (thanks @meriturva 👍 )

We'll work on fixing this ASAP

[Mpdreamz]

Coming back to this I don't think this is a bug albeit a very very subtle nuance:

var esResponse = await elasticClient.MultiGetAsync(m => m
    .Index(_fullIndexName)
    .GetMany<EsSdMetadataProfile>(fqns)
);

Means do an _mget on /{_fullIndexName}/_mget and give me all the EsSdMetadataProfile objects where each get operation will be seeded with IndexName<EsSdMetadataProfile>(). However unless you configure EsSdMetadataProfile default index we have no way of knowing whether that is the default object from the index.

var esResponse = await elasticClient.MultiGetAsync(m => m
    .Index(_fullIndexName)
    .GetMany<EsSdMetadataProfile>(fqns)
    .GetMany<OtherObject>(fqns)
);

Is equally valid where we don't know if both objects are intended to live in _fullIndexName or one of them is. The index in the url of the API only serves as a default e.g if you do an /blah/_mget individual gets within the body can still do gets outside of blah.

The fix is as the exception describes, configure a default index name on connection settings for the type or be explicit:

var esResponse = await elasticClient.MultiGetAsync(m => m
    .Index(_fullIndexName)
    .GetMany<EsSdMetadataProfile>(fqns, (g, id) => g.Index(_fullIndexName))
    .GetMany<OtherObject>(fqns, (g, id) => g.Index("someotherindex"))
);

Which is exactly what the helper client.GetMany() does for you.

[TheFireCookie]

Hello,
Thank you for your fast analysis.

The weird thing is that this exact code is working in NEST 7.5.1.
But I can change my code if it seems like the better approach to use GetManyAsync instead of multiget :) What do you think?

Matthias.

[Mpdreamz]

I think that's the best course of action. With 8.0 we will very likely remove this special routine to try and clean up index on the get operations which will cause the same behaviour.