Summary
Several public byte counters are cumulative u64 values but serialize as JSON numbers. The repo invariant says values that can exceed JavaScript exact integer range, including byte counters, should serialize as decimal strings.
Code paths
- crates/s3tap-schema/src/lib.rs - Connection::bytes_sent
- crates/s3tap-schema/src/lib.rs - Connection::bytes_recv
- crates/s3tap-schema/src/lib.rs - Connection::bytes_retrans
- crates/s3tap-schema/src/lib.rs - TcpSample::bytes_sent
- crates/s3tap-schema/src/lib.rs - TcpSample::bytes_recv
Impact
Large long-lived connections or sampled counters can exceed 2^53, so JS and jq style consumers can lose precision. Changing this is a public wire-format change and should be handled with an intentional schema bump rather than silently changing the existing tags.
Suggested direction
Decide whether to spend a schema bump before public release. If not, document this as a known wire-format limitation for the current schema version and fix in the next schema bump.
Summary
Several public byte counters are cumulative u64 values but serialize as JSON numbers. The repo invariant says values that can exceed JavaScript exact integer range, including byte counters, should serialize as decimal strings.
Code paths
Impact
Large long-lived connections or sampled counters can exceed 2^53, so JS and jq style consumers can lose precision. Changing this is a public wire-format change and should be handled with an intentional schema bump rather than silently changing the existing tags.
Suggested direction
Decide whether to spend a schema bump before public release. If not, document this as a known wire-format limitation for the current schema version and fix in the next schema bump.