ElasticClient.Get<T>(...) fails with Could not parse server exception when document doesn't exist

[kohner86]

When doing a get request on a document which doesn't exist (it was deleted) the call throws an exception of type 'Elasticsearch.Net.ElasticsearchServerException' with a message of 'Could not parse server exception' with the following stack trace:

at Nest.ElasticClient.<>c__DisplayClass2614.b__260(Task1 r) in c:\Users\gmarz\code\elasticsearch-net\src\Nest\ElasticClient.cs:line 145
at System.Threading.Tasks.ContinuationResultTaskFromResultTask2.InnerInvoke() at System.Threading.Tasks.Task.Execute() --- 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.TaskAwaiter1.GetResult()
at WorkerRoleService.InstagramV2.QueryActor.d__6b.MoveNext() in c:\Zoomph\Web\Azure\myStanlyWeb\Releases\Brontosaurus\myStanlySolution\WorkerRoleService\InstagramV2\QueryActor.cs:line 622

Is this expected behavior? The IGetResponse interface has a 'Found' property on it which I would expect to check to see if the get failed rather than the exception being thrown.

We're using NEST 1.1.1 with Elastic Search 1.3.4

-Lee

[gmarz]

@kohner86 An exception/error is definitely not the expected behavior here. IsValid should be true and Found should be false in this case.

I just pushed the above fix. The issue was that the get endpoint returns a 404 when a document doesn't exist and NEST was treating it as an error. For most endpoints a 404 is an error, but there are a few (get, delete, exists, etc...) where a 404 is a valid response.

Really good catch- thank you for reporting!

[HunterMcEwan]

Seems like Get (and Delete) were removed from the 404-is-valid list in 0992779, was this intentional?