Provide `arbitrary_precision` option for `serde_json` float conversions

[DominikMoelter]

A note for the community

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Problem

When using parse_json() with some float numbers the return value contains numbers which do not match with the input data.

I'm using this config

sources:
  dummy_logs:
    type: "demo_logs"
    format: "shuffle"
    interval: 5
    lines:
    - '{"coordinates":[0.12379999458789825,0.05209999904036522,-0.1266999989748001]}'
    - '{"coordinates":[-0.24199999868869781,-0.07459999620914459,-0.0032999999821186066]}'
      
transforms:
  parse_json:
    type: remap
    inputs: 
      - dummy_logs
    source: |
      . = parse_json!(.message)

sinks:
  console_out:
    type: console
    inputs:
      - parse_json
    encoding:
      codec: json

The output shows

2025-08-27T14:29:19.211496Z  INFO vector::app: Log level is enabled. level="info"
2025-08-27T14:29:19.212886Z  INFO vector::app: Loading configs. paths=["."]
2025-08-27T14:29:19.216547Z  INFO vector::topology::running: Running healthchecks.
2025-08-27T14:29:19.216665Z  INFO vector: Vector has started. debug="false" version="0.49.0" arch="x86_64" revision="dc7e792 2025-08-12 13:47:08.632326804"
2025-08-27T14:29:19.216682Z  INFO vector::app: API is disabled, enable by setting `api.enabled` to `true` and use commands like `vector top`.
2025-08-27T14:29:19.216810Z  INFO vector::topology::builder: Healthcheck passed.
{"coordinates":[-0.2419999986886978,-0.07459999620914459,-0.0032999999821186066]}
{"coordinates":[0.12379999458789824,0.05209999904036522,-0.1266999989748001]}

As you can see in this example both first array entries do not match with the input data. This does not always happen, so there is also data which is parsed correctly.

Configuration

Version

vector 0.49.0 (x86_64-unknown-linux-gnu dc7e792 2025-08-12 13:47:08.632326804)

Debug Output

Example Data

{"coordinates":[0.12379999458789825,0.05209999904036522,-0.1266999989748001]}
{"coordinates":[-0.24199999868869781,-0.07459999620914459,-0.0032999999821186066]}

Additional Context

No response

References

No response

[thomasqueirozb]

Playground

[Mr-iX]

I have the same issue, how can can we mitigate that?

[daskanu]

I came across the issue by chance and noticed that the problem also affects my use case. Could a developer comment on what's going on here? It seems to occur somewhere beyond the 16th decimal place.

[pront]

Reproduction steps:

1. Input:

{"num": 0.12379999458789825}

2. VRL program:

. = .num

3. Command:

cargo run --color=always --bin vrl --profile dev --manifest-path vrl/lib/cli/Cargo.toml -- --print-warnings --program vrl/pront/vrl_scripts/float_loss.vrl --input vrl/pront/inputs/float_loss.json

Debug output:

number: 0.12379999458789825
number as f64: 0.12379999458789825

Explanation:
The conversion happens inside serde_json, so at this point
https://github.com/vectordotdev/vrl/blob/main/src/cli/cmd.rs#L234, we already lose precision.

The serde_json crate provides https://docs.rs/crate/serde_json/1.0.143/features#arbitrary_precision and I confirmed locally that setting this feature changes the result to 0.12379999458789825.

I would argue this is working as designed, since arbitrary_precision is not set because of the performance overhead it introduces. Ideally, we would be able to configure this behavior and let users choose.

Awkward Workaround:
If your downstream system can accept strings and you don't need to do operate on these values, you can use strings e.g. "0.12379999458789825" to have arbitrary precision.