I'm doing some custom error handling/logging with Elasticsearch in a .NET environment using Elasticsearch.NET. Given an IResponse object, I'm trying to arrive at the best strategy for plucking out a short, succinct, and useful "root cause" message. I originally arrived at this, which works great when we come across indexing errors specifically:
shortMsg = response.ServerError?.Error?.RootCause?.FirstOrDefault()?.Reason;
But I recently ran into a query-time error where the above gave me this:
"failed to create query: { ... }"
(Details left out, but it effectively dumped the entire query.)
Since that isn't particularly useful, I spent a little time traversing the response to see what else is available. response.ServerError.Error.Reason, for example, returns "all shards failed" - also not particularly useful. response.DebugInformation is much bigger than what I'd like for this particular purpose, but I did find the needle in the haystack I was looking for toward end of it:
"Can't parse boolean value [True], expected [true] or [false]"
That's perfect, and to avoid parsing it out of DebugInfomation I also managed to find it here:
response.ServerError.Error.Metadata.FailedShards.First().Reason.CausedBy.Reason
So at this point I've arrived at this strategy to get my shortMsg:
shortMsg =
response.ServerError?.Error?.Metadata?.FailedShards?.FirstOrDefault()?.Reason?.CausedBy?.Reason ??
response.ServerError?.Error?.RootCause?.FirstOrDefault()?.Reason;
My concern with this is that it might be naive to assume that if something exists along the first path, it'll always be "better" than the second. A better understanding of the response structure itself might be key to arriving at the best strategy here.
Any suggestions on improving this?
