feat(ingester): derive event_name from the legacy event.name attribute (RFC 0043 slice 1)

[jensholdgaard]

Summary

RFC 0043 slice 1 — the derivation itself, at the one seam both encodings share (materialize_record):

• A non-empty wire event_name always wins (RFC0043.1).
• Unset-or-empty wire field + non-empty string event.name attribute → the field is derived; the attribute stays byte-identical in attributes (RFC0043.2).
• Non-string, empty-string, and JSON-null attribute values derive nothing (RFC0043.4/.7); an empty wire field counts as unset per the existing RFC0003.9 proto3 narrowing.
• The RFC0003.6 JSON path is exercised through the real decode_json (RFC0043.3, and the .7(c) null shape), so the two encodings provably agree.

Slice 2 (separate PR) covers RFC0043.5 (the event_name == query end-to-end) and RFC0043.6 (the observable event-keyed templating collapse).

Invariants / hazards

OTLP fidelity (preserve / flag / never correct): holds by construction — nothing received is altered or dropped; the derived field is additive and every test asserts the attribute round-trips byte-identical, including on the mismatch path (RFC0043.1 treats a wire/attribute disagreement as source telemetry, preserved unflagged).

Verification

cargo fmt --check, cargo clippy -p ourios-ingester --all-targets --all-features (0 warnings), full ourios-ingester suite green incl. the 5 new RFC0043 tests.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Qtny6z6cA74xPZa4qRhk4F

[coderabbitai]

Warning

Review limit reached

@jensholdgaard, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 12 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 682a86e5-9df7-4742-a951-6db5fea42f5d

📥 Commits

Reviewing files that changed from the base of the PR and between 260ad52 and f151535.

📒 Files selected for processing (3)

• crates/ourios-ingester/src/receiver/materialize.rs
• crates/ourios-ingester/tests/it/main.rs
• crates/ourios-ingester/tests/it/rfc0043_event_name_derivation.rs

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

Pull request overview

Implements RFC 0043 slice 1 in the ingester by deriving the event_name field from the legacy event.name attribute at the shared materialize_record boundary, ensuring consistent behavior across protobuf and OTLP/JSON decode paths while preserving inbound attributes verbatim.

Changes:

• Derive event_name from event.name when the wire event_name is unset/empty, while ensuring a non-empty wire value always wins.
• Add RFC0043 integration tests covering wire-wins, derivation, JSON/protobuf equivalence, non-string handling, and empty/null cases.
• Register the new RFC0043 test module in the integration test harness.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
crates/ourios-ingester/src/receiver/materialize.rs	Adds event_name derivation logic at materialize_record using the legacy event.name attribute when appropriate.
crates/ourios-ingester/tests/it/rfc0043_event_name_derivation.rs	Adds RFC0043 scenario tests validating derivation rules and JSON/protobuf equivalence.
crates/ourios-ingester/tests/it/main.rs	Wires the new RFC0043 integration test module into the test suite.

Comments suppressed due to low confidence (3)

crates/ourios-ingester/tests/it/rfc0043_event_name_derivation.rs:88

• Test scenario docs in this integration-test suite consistently include a See docs/rfcs/... §5 line under the /// Scenario ... header for greppability and to link back to acceptance criteria. This scenario is missing that reference line.

/// Scenario RFC0043.3 — both encodings derive identically. The JSON
/// payload spells the record per RFC0003.6 (lowerCamelCase, no wire
/// `eventName`); decoding yields the same proto structs the protobuf
/// path produces, so one materialisation covers both.
#[test]
fn rfc0043_3_json_and_protobuf_paths_agree() {

crates/ourios-ingester/tests/it/rfc0043_event_name_derivation.rs:116

• Test scenario docs in this integration-test suite consistently include a See docs/rfcs/... §5 line under the /// Scenario ... header for greppability and to link back to acceptance criteria. This scenario is missing that reference line.

/// Scenario RFC0043.4 — a non-string `event.name` derives nothing.
#[test]
fn rfc0043_4_non_string_attribute_derives_nothing() {

crates/ourios-ingester/tests/it/rfc0043_event_name_derivation.rs:135

• Test scenario docs in this integration-test suite consistently include a See docs/rfcs/... §5 line under the /// Scenario ... header for greppability and to link back to acceptance criteria. This scenario is missing that reference line.

/// Scenario RFC0043.7 — empty is never a value, in either position:
/// (a) an empty wire field is unset (proto3 cannot distinguish absent
/// from empty), so the attribute derives; (b) an empty-string attribute
/// derives nothing; (c) a JSON `null` value derives nothing.
#[test]
fn rfc0043_7_empty_is_never_a_value() {

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.