Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A call to client.Cluster.StatsAsync fails with JSON serialization error #8015

Closed
yansklyarenko opened this issue Jan 19, 2024 · 7 comments · Fixed by #8129
Closed

A call to client.Cluster.StatsAsync fails with JSON serialization error #8015

yansklyarenko opened this issue Jan 19, 2024 · 7 comments · Fixed by #8129
Labels
8.x Relates to 8.x client version Area: Specification Category: Bug

Comments

@yansklyarenko
Copy link

Elastic.Clients.Elasticsearch version: 8.11.0

Elasticsearch version: 8.11.0

.NET runtime version: net7.0, net6.0

Operating system version: Windows 10

Description of the problem including expected versus actual behavior:
Run a plain request to get cluster stats:

var stats = await client.Cluster.StatsAsync(new ClusterStatsRequest()).ConfigureAwait(false);

It fails with the following error:

The JSON value could not be converted to System.Int32. Path: $.indices.query_cache.total_count

Notes
This is only happening when the total_count property of the query_cache object of the target cluster exceeds the int.MaxValue. In my case, if I run the same query in the ES console, I get 2153022551 for the .indices.query_cache.total_count, which is obviously bigger than int.MaxValue (2147483647).
The type of the TotalCount property is int, but should probably be long.

@yansklyarenko yansklyarenko added the 8.x Relates to 8.x client version label Jan 19, 2024
@flobernd
Copy link
Member

Hi, thanks for reporting. This looks like a specification issue. As far as I can tell, all other places are using long for total_count.

@yansklyarenko
Copy link
Author

At this point, I ended up with a workaround to issue a plain REST request to /_cluster/stats and parse the raw JSON response.

@milos-matic-comparis
Copy link

Hey @flobernd, do you maybe have an ETA when these changes are gonna be available within .net libraries? 🤔

We're experiencing the same issue for some time now, and I was wondering should I do a workaround or wait for a proper fix? :)

Regards,
Milos

 "query_cache": {
                    "memory_size_in_bytes": 0,
                    "total_count": 606209036,
                    "hit_count": 206640531,
                    "miss_count": 399568505,
                    "cache_size": 0,
                    "cache_count": 33375558,
                    "evictions": 33375558
                } 

@flobernd
Copy link
Member

Hi @milos-matic-comparis! Did you try the latest 8.13 version? The fix should be included there 🙂

@milos-matic-comparis
Copy link

milos-matic-comparis commented Apr 15, 2024

606209036

Hey @flobernd, I did try with 8.12.1, 8.13.0 and 8.13.5 but it's still throwing the same exception. I also bumped up Elastic.Transport 0.4.18 :(

Stack trace with 8.13.0:
The JSON value could not be converted to System.Int32. Path: $._all.primaries.query_cache.total_count | LineNumber: 0 | BytePositionInLine: 1617.
and with 8.13.5
The JSON value could not be converted to System.Int32. Path: $._all.primaries.query_cache.total_count | LineNumber: 0 | BytePositionInLine: 1618.

Still, we will probably wait for future releases since upgrading to 8.13.x and Elastic.Transport also introduces dependency to System.Text.Json 8.x.x and that is not an easy thing to upgrade in our system :D

I'll keep an eye to the changelogs for sure :)

@flobernd
Copy link
Member

Ouch. I see the problem now. My PR in the specification repository changed the type in the wrong place. I'll fix that 🙂

@milos-matic-comparis
Copy link

Great, tnx for the effort 🤓

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
8.x Relates to 8.x client version Area: Specification Category: Bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants