feat(semconv): register datafusion.operator.* attributes (RFC 0040 slice 2) - #633
Conversation
…ice 2) The five normative operator-span attributes (output_rows, elapsed_compute, output_bytes, row_groups_pruned, row_groups_matched) go through the weaver registry as their own registry.datafusion group -- separate from registry.ourios, since these describe DataFusion's semantics, not Ourios's, per RFC 0040 §3.3. ourios-df-otel keeps its own local string constants (it cannot depend on ourios-semconv without breaking the crate's zero-ourios-dep extraction design); this registration is what lets `weaver registry live-check` validate the names once slice 3 wires emission into the querier, rather than flagging them as unregistered. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Qtny6z6cA74xPZa4qRhk4F Signed-off-by: Jens Holdgaard Pedersen <Jens@holdgaard.org>
|
Warning Review limit reached
Next review available in: 29 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?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 reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. 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, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✨ 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
Registers the RFC 0040 §3.3 datafusion.operator.* attribute keys in the Weaver semconv registry so future operator-span emission (slice 3) can pass weaver registry live-check without “unregistered attribute” violations.
Changes:
- Add a new
registry.datafusionattribute group defining fivedatafusion.operator.*attributes. - Regenerate
crates/ourios-semconv/src/lib.rsto include the corresponding constant keys.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| semconv/registry/attributes.yaml | Adds registry.datafusion and defines the five operator-span attributes. |
| crates/ourios-semconv/src/lib.rs | Regenerated semconv constants for the new datafusion.operator.* keys. |
Comments suppressed due to low confidence (1)
semconv/registry/attributes.yaml:366
- The brief for
datafusion.operator.row_groups_matchedcalls this value the “B1 denominator”, which is an Ourios benchmark-specific concept. To keep this attribute definition reusable outside Ourios (as the surrounding comment suggests), remove the B1 reference and describe only the DataFusion/Parquet meaning.
Parquet row groups this scan read (`PruningMetrics::matched`) —
the B1 denominator. Reported as a raw count alongside
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
… briefs Copilot review on PR #633: the row_groups_pruned/matched briefs referenced Ourios's B1 benchmark gate, which contradicts the group's own stated intent (DataFusion-owned semantics, extractable to a standalone component). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Qtny6z6cA74xPZa4qRhk4F Signed-off-by: Jens Holdgaard Pedersen <Jens@holdgaard.org>
Summary
registry.datafusiongroup insemconv/registry/attributes.yaml: the five normative operator-span attributes RFC 0040 §3.3 specifies (output_rows,elapsed_compute,output_bytes,row_groups_pruned,row_groups_matched) — kept as their own group, separate fromregistry.ourios, since they describeDataFusion's semantics, not Ourios's (the crate is built to be extracted to a standalonedatafusion-contribcomponent).crates/ourios-semconv/src/lib.rs(weaver registry generate) — 5 new constants, no other diff.ourios-df-otel(merged in slice 1, feat(df-otel): post-hoc ExecutionPlan -> OTel operator span crate (RFC 0040 slice 1) #632) keeps its own local string constants rather than depending onourios-semconv— that dependency would break its zero-ourios-*-dep design. This registration exists soweaver registry live-checkrecognizes the names once slice 3 wires emission intoourios-querier, instead of flagging them as unregistered violations.Related
RFC:
docs/rfcs/0040-datafusion-operator-instrumentation.md(slice 2 of 4)Checklist
weaver registry check -r semconv/registry --futurecleanweaver registry generate+cargo fmt -p ourios-semconvproduces exactly this diff (no drift)cargo test -p ourios-semconv --all-features(3/3 pass)cargo clippy -p ourios-semconv --all-targets --all-features -- -D warningscleancargo fmt -p ourios-semconv --checkcleanCHANGELOG.md— not user-facing yet (no emission until slice 3)