Nodes.StatsAsync(x => x.Human()) Fails with Utf8Json.JsonParsingException

[J-Griffin]

NEST/Elasticsearch.Net version: 7.13.2

Elasticsearch version: 7.13.4

.NET runtime version: 4.7

Operating system version: Windows 10 (Dev machine)

Description of the problem including expected versus actual behavior:
Calls to node stats with the "human" param fail with a deserialization exception.

Steps to reproduce:

1. Call node stats:

var client = new ElasticClient(settings);
var nodeStats = client.Nodes.StatsAsync(stats => stats.Human());

2. See Elasticsearch.Net.Utf8Json.JsonParsingException exception thrown with message:
   {"expected:'Number Token', actual:'\"34.7ms\"', at offset:13214"}

Expected behavior
The NodesStatsResponse should be returned (successful request or not). Excluding "human" resolves the issue. The json parsing fails because Nest.AdaptiveSelectionStats.AverageResponseTime is a long, but should be a string.

This works:

var nodeStats = client.Nodes.StatsAsync();

Preventing the "adaptive_selection" section from returning also works:

var nodeStats = client.Nodes.StatsAsync(stats => stats
    .Metric(NodesStatsMetric.Breaker | NodesStatsMetric.Jvm | NodesStatsMetric.Fs)
    .Human());

[stevejgordon]

@J-Griffin Thanks for raising this issue. It's interesting on a few levels. The first thing I'd like to understand is your scenario which requires requesting a human-readable response. Since this is essentially a machine situation, I wouldn't expect responses in the human-readable form to deserialise into our types, which is the case here. When using the High-Level NEST client, the types are modelled on the machine-readable JSON responses.

The .Human option can be used with the low-level client where you receive the raw bytes/string/etc. containing the JSON and can use that for your own bespoke requirements.

The fact you're receiving that exception is not unexpected, but I agree, we may be able to consider if that should be caught internally with the failure being identified on the response object. I believe right now this is likely by design since, for the standard case, we never expect the JSON deserialisation to fail and when it does, this is a more explicit identification and failure.

[J-Griffin]

@stevejgordon on the one hand, I agree it's a bit odd, but on the other, Human() is explicitly in the NEST syntax AND properties like AverageResponseTime (which is only populated when specifying human) are in the response classes. So they should at least return successfully.

Our specific case is for some basic dashboarding where we want to highlight basic human readable values we find valuable. The least effort way of doing that is/was to call stats endpoints with "human" to use the already formatted strings instead of parsing bytes, time values, etc.

[stevejgordon]

@J-Griffin My apologies for letting the ball drop on this issue. I took a fresh look and agree, that currently this is supported for other properties and this particular property is mistyped. I have fixed this in #6107 and will get that into the next release. Sorry, it took so long to resolve this one.