Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

json: a build with `serde_json/arbitrary_precision` rejects every number outside the `i64` and `u64` integer ranges

Open
  • Is something wrong?
#482 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
json, rust
Domain
backend

Research direction

Start by locating buffa's visitors for float, double, and integer fields, then reproduce the serde_json arbitrary_precision examples in the issue. Trace how the deserializer represents out-of-range, fractional, and exponent numbers. Done means those numbers decode correctly while ordinary JSON objects remain objects and existing i64/u64 behavior is preserved.

Written by the indexing model from the issue text.

Description

enhancement

buffa's JSON decoding rejects every number that is not an integer in the i64 or u64 range when serde_json's arbitrary_precision feature is enabled by any crate in the build. That is every number with a fraction or an exponent, and every integer above u64::MAX or below i64::MIN. Cargo unifies features across a build, so a dependency that enables the feature for its own types changes how buffa decodes.

Reproduce

[dependencies]
buffa-types = { version = "0.9", features = ["json"] }
serde_json = { version = "1", features = ["arbitrary_precision"] }

use buffa_types::google::protobuf::{DoubleValue, Struct};

// Err: invalid type: map, expected a double, "NaN", "Infinity", "-Infinity", or null at line 1 column 3
serde_json::from_str::<DoubleValue>("1.5");

// Err: invalid type: map, expected a double, ... — a `double` field, for an integer above u64::MAX
// {"doubleValue": 18446744073709551616}

// Err: invalid type: map, expected a u64 as a quoted decimal string, integer, float, or null — a `uint64` field
// {"positiveIntValue": 1e3}

// Ok, but the value of "a" is a struct with the one key "$serde_json::private::Number"
serde_json::from_str::<Struct>(r#"{"a": 1.5}"#);

Integers in the i64 and u64 ranges decode as they do without the feature.

Cause

With arbitrary_precision, serde_json's deserializer keeps the text of a number that does not parse as an i64 or a u64. It hands that number to a visitor through visit_map, as an object with the one key $serde_json::private::Number and the text as the value. serde_json's own Number and Value types read that key. buffa's visitors for float, double and integer fields implement no visit_map, so they reject the map. The visitor for google.protobuf.Value reads the map as a struct.

What a fix needs

Each numeric visitor would accept that map and parse the text. The visitors cannot read the key unconditionally: in a build without the feature, the same object in the JSON text is an ordinary object, and must not decode as a number. The feature is not visible to buffa at compile time, because another crate can enable it, so the visitors need a runtime check that the deserializer produces the key for a number.

Until then, arbitrary_precision is documented as unsupported.

Dominant language
Rust
Stars
900
Forks
95
Avg merge
5d 10h
Merged PRs (30d)
57

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from anthropics/buffa

All issues in anthropics/buffa

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.