GetAsync fails when specifying a null index.

[niemyjski]

We have some generic code that runs and trys to specify an index for getbyid but if it can't be found it returns null. This worked in <2.0 of the client I believe this is a bug.

Fails:

var response = await elasticClient.GetAsync<T>(id, s => s.Index(null));


System.ArgumentException

Dispatching Get() from NEST into to Elasticsearch.NET failed
Received a request marked as GET
This endpoint accepts GET
The request might not have enough information provided to make any of these endpoints:
  - /{index=<NULL>}/{type=employee}/{id=56fed5baae14593188842ee5}


   at Nest.LowLevelDispatch.GetDispatchAsync[T](IRequest`1 p) in C:\users\russ\source\elasticsearch-net\src\Nest\_Generated\_LowLevelDispatch.generated.cs:line 932
   at Nest.ElasticClient.<Nest-IHighLevelToLowLevelDispatcher-DispatchAsync>d__24`4.MoveNext() in C:\users\russ\source\elasticsearch-net\src\Nest\ElasticClient.cs:line 75
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
   at Foundatio.Elasticsearch.Repositories.ElasticReadOnlyRepositoryBase`1.<GetByIdAsync>d__15.MoveNext() in C:\Code\Foundatio.Repositories\src\Elasticsearch\Repositories\ElasticReadOnlyRepositoryBase.cs:line 196

Works:

var response = await elasticClient.GetAsync<T>(id);

[niemyjski]

If you pull down foundatio repositories project and run the tests you'll run into this.

[gmarz]

You need to specify an index when getting a document. This exception is telling you exactly that. If it worked in 1.x then it was wrong :).

[niemyjski]

If I pass null to the index that's the same as not specifying one.. They should work the same

[niemyjski]

I feel pretty strongly that this is a bug in the client

[gmarz]

When you don't specify an index, it's being inferred from T. Passing null explicitly is overriding the inferred index.

[niemyjski]

I get this but what use case would you ever pass null in here and get a valid query?

[niemyjski]

And if you'd never get a valid query then, should we throw a argumentnullexception? This difference really threw me off guard. As a lot of tests started failing.

[gmarz]

I get this but what use case would you ever pass null in here and get a valid query?

Exactly. This is why we throw the exception when you pass it null.

I get your point as well, but we try to generalize this logic for all API calls within LowLevelDispatch, so if any required part of the path is missing we throw. For some calls it's valid to override the inferred index and set it to null (_search for instance).

[niemyjski]

The stack trace is terrible due to how its executed :(

[gmarz]

But

System.ArgumentException

Dispatching Get() from NEST into to Elasticsearch.NET failed
Received a request marked as GET
This endpoint accepts GET
The request might not have enough information provided to make any of these endpoints:
  - /{index=<NULL>}/{type=employee}/{id=56fed5baae14593188842ee5}

Is pretty descriptive :)

[niemyjski]

Yes, it's much better than what it is but kinda of misleading until your used to all the new stack traces. I was expecting a request to be made and failed so I was looking in fiddler first ready to grab the request json.

[gmarz]

Gotcha. Going to close this. Please do keep opening issues though as you run into things. 👍

[gmarz]

@niemyjski I stand corrected here :)

Discussed this further with @Mpdreamz and @russcam and it makes sense for .Index(null) to behave as if it was never called. This is a general rule the fluent API should follow everywhere.