feat: rfc0018.5 green — non-finite doubles round-trip; RFC 0018 green - #271
Conversation
|
Warning Review limit reached
More reviews will be available in 26 minutes and 14 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR completes RFC 0018 scenario .5 by making Ourios-canonical JSON round-trip NaN/Infinity/-Infinity for AnyValue and attribute values, and flips RFC 0018’s overall status to green.
Changes:
- Add a guarded “robust” canonical JSON encode/decode path that uses proto3-JSON string forms for non-finite doubles while keeping the existing fast path for finite values.
- Turn RFC0018.5 from an ignored red stub into a green acceptance test covering top-level, nested structured bodies, and attributes.
- Update RFC 0018 document status from
redtogreen.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| docs/rfcs/0018-otlp-log-spec-compliance.md | Marks RFC 0018 as green now that all acceptance scenarios pass. |
| crates/ourios-core/src/otlp.rs | Implements non-finite double handling in canonical JSON encode/decode (AnyValue + attributes), plus updates the pinned non-finite-double test. |
| crates/ourios-core/tests/rfc0018_otlp_compliance.rs | Adds the RFC0018.5 green test asserting non-finite doubles round-trip in multiple placements. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
serde_json renders a non-finite f64 as JSON null (lossy: NaN/±Inf collapse
to one shape, and opentelemetry-proto's deserializer rejects both null and
the proto3 string form for an f64 field), so a structured Body / attribute
carrying NaN/Infinity/-Infinity didn't round-trip (RFC 0018 §3.4).
Add a guarded robust path to ourios-core's canonical codec: when — and only
when — a non-finite double is present, encode/decode walk the AnyValue tree
and use the proto3-JSON string forms ("NaN"/"Infinity"/"-Infinity"),
delegating finite/string/int/bytes leaves to opentelemetry-proto's exact
serde. The finite case stays on the untouched #130-bit-exact fast path.
encode_attributes/decode_attributes get the same treatment for attribute
values. (No serde direct-dep: custom-error via serde_json::Error::io.)
Greens RFC0018.5 (round-trip at top level, nested in a structured body, and
as an attribute value) and overturns the pinned "encodes to null" test
(§6.2 contract change). RFC 0018 status red → green — all six §5 scenarios
pass (.1/.2/.3/.4/.5/.6).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
4e49ca4 to
e62a416
Compare
Copilot: the module-level canonical-JSON doc and CanonicalJsonError doc still said non-finite doubles encode as JSON null and do not decode. That was the pre-RFC0018.5 behaviour; the canonical codec now round-trips them via the proto3-JSON string forms (NaN/Infinity/-Infinity) on a guarded path. Update both comments to match. Doc-only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…anonical (#333) * docs(querier): finish #177's doc sweep — the codec is Ourios-canonical, not OTLP-canonical The last two stale mentions from #177's ride-along list: compile.rs still called the attributes-column encoding "OTLP-canonical-JSON". Post-#166 the codebase convention is "Ourios-canonical" — deliberately so, since the codec deviates from opentelemetry-proto's with-serde exactly where with-serde deviates from the proto3 JSON mapping (non-finite doubles as "NaN"/"Infinity"/"-Infinity" strings, RFC 0018 §3.4 — the #177 core bug, fixed in #271). Doc-comment-only change. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs: complete the repo-wide Ourios-canonical sweep (miner + parquet) Copilot caught that my "last remaining mentions" claim was wrong — I had grepped for cluster.rs / record_batch.rs under ourios-querier, where those files don't exist (they live in ourios-miner and ourios-parquet), and misread no-matches as already-clean. Repo-wide sweep now: - cluster.rs: rename the §3.3 encoding mention, and rewrite the genuinely stale test note that still described `body` as "the AnyValue's Debug form — an interim placeholder" awaiting a future canonicalisation PR (that PR landed long ago; the body is the Ourios-canonical JSON from `ingest_structured` → `canonical::encode_any_value`). - record_batch.rs: rename both mentions. The remaining "OTLP-canonical" hits in docs/ are historical amendment notes that *describe* the old name (e.g. RFC 0001/0005 "previously called the encoding…") and are correct as written. Comment-only; `cargo grep` for OTLP-canonical in crates/ is now empty. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
RFC 0018 green (6/6) — non-finite doubles round-trip; RFC 0018 fully green (RFC0018.5)
serde_jsonrenders a non-finitef64as JSONnull— lossy (NaN/±Inf collapse to one shape), andopentelemetry-proto's deserializer rejects bothnulland the proto3 string form for anf64field (verified). So a structuredBody/ attribute carryingNaN/Infinity/-Infinitysilently dropped the value (RFC 0018 §3.4).Fix — a guarded robust path (round-trip is the §3.3 "canonical" contract)
When and only when a non-finite double is present,
ourios-core's canonical encode/decode walk theAnyValuetree and use the proto3-JSON string forms ("NaN"/"Infinity"/"-Infinity"), delegating finite/string/int/bytes leaves toopentelemetry-proto's exact serde. The finite case stays on the untouched#130-bit-exact fast path. Same forencode_attributes/decode_attributes. (No newserdedirect-dep — custom errors viaserde_json::Error::io.)Verification
ourios-core/tests): round-trips at top level, nested in a structured body (kvlist+arraymixing the three non-finite with finite doubles and strings), and as an attribute value.nonfinite_doubles_encode_to_the_null_shapetest →…round_trip_via_proto3_strings(a §6.2 contract change the RFC authorizes).clippy --all-targets,fmt,mdbook, semconv no-diff clean. NaN payloads canonicalise (proto3 doesn't preserve them) — value-equality is the contract.RFC 0018 status flipped
red → green— all six §5 scenarios pass.🤖 Generated with Claude Code