test(querier): rfc0044.6 — renames and reversions, no alias expansion

[jensholdgaard]

Summary

RFC 0044 slice 3 — the .6 criterion, with a design refinement stated inline in the RFC:

• The scenario: a template re-created under a new id after a deploy (the RFC 0010 drift shape) plus a same-shape sibling — body == returns the byte-identical records under both ids and excludes the record whose params differ. Registry-wide unification is what provides this: every (template_id, version)'s tokens are in the fold, so renames and reversions contribute inherently.
• The refinement: the RFC's original §3.3 said the match "traverses versions and aliases". Implementing it surfaced that expanding RFC 0007 alias classes would be wrong, not just unnecessary — alias classes group templates whose shapes differ, and byte-equality must never admit a record whose own tokens do not render the literal. resolves_to(n) remains the query for shape-crossing equivalence. §3.3 and the .6 criterion now say exactly that, refinement visible.

Verification

8/8 rfc0044 it scenarios green; fmt clean; mdbook build clean.

🤖 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: 19 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: 911cba86-903b-4219-9ed4-60566219cedc

📥 Commits

Reviewing files that changed from the base of the PR and between 752c455 and 56a3703.

📒 Files selected for processing (2)

• crates/ourios-querier/tests/it/rfc0044_body_equality.rs
• docs/rfcs/0044-template-aware-body-equality.md

---

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

This PR updates RFC 0044’s definition of plan-time body == matching to explicitly exclude RFC 0007 alias-class expansion (since alias classes can cross shapes), and adds/renames the RFC0044.6 integration scenario in ourios-querier to validate the intended “rename/re-create under new id” drift shape.

Changes:

• Refines RFC 0044 §3.3 and criterion RFC0044.6 to state that matching is driven by registry-wide token unification across ids/versions, while explicitly excluding alias-class expansion.
• Adds the RFC0044.6 querier integration test scenario for the “template re-created under a new id” drift case and asserts byte-equality excludes rows whose own tokens don’t render the literal.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
docs/rfcs/0044-template-aware-body-equality.md	Refines RFC text to clarify rename/version contribution and explicitly exclude alias-class expansion for body ==.
crates/ourios-querier/tests/it/rfc0044_body_equality.rs	Adds RFC0044.6 integration scenario covering the “re-created under a new id” drift shape and asserts exact matching behavior.

---

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

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

crates/ourios-querier/tests/it/rfc0044_body_equality.rs:245

• With the widening represented as a fixed-token→wildcard change, the widened (v2) record should keep the same token/separator count as v1 and add one extra param for the newly-wildcarded position. The current fixture uses a different separator vector (sep7) and an extra literal token (EXTRA), which implies a length-changing widening. Adjust the v2 record to use sep6 and three params so it matches the v2 template shape.

    let sep6 = ["", " ", " ", " ", " ", " ", ""];
    let sep7 = ["", " ", " ", " ", " ", " ", " ", ""];
    write_all(
        bucket.path(),
        &[
            mined("t", 2, TS0 + 10, &["999", "1.2.3.4"], &sep6),
            mined("t", 7, TS0 + 20, &["999", "1.2.3.4"], &sep6),
            mined("t", 7, TS0 + 30, &["888", "1.2.3.4"], &sep6),
            // Written under the widened (2, v2).
            MinedRecord {
                template_version: 2,
                ..mined("t", 2, TS0 + 40, &["999", "1.2.3.4", "EXTRA"], &sep7)
            },
        ],

crates/ourios-querier/tests/it/rfc0044_body_equality.rs:264

• The widened-version assertion currently uses a literal with an extra trailing token. If the widening is modeled as a fixed-token→wildcard change (same token count), update the query literal accordingly so it matches only the v2 record created above.

    let widened = run(
        bucket.path(),
        r#"body == "user 999 logged in from 1.2.3.4 EXTRA""#,
    )
    .await;
    assert_eq!(
        widened.rows, 1,
        "the widened version's tokens key separately and match their own render"
    );

crates/ourios-querier/tests/it/rfc0044_body_equality.rs:229

• The fixture models TemplateChange::Widened as appending a new trailing <*> token ("... <*> <*>"), but the miner’s widening logic only widens by turning existing Fixed token positions into Wildcard and assumes the line/template token lengths are equal (find_widening_positions has debug_assert_eq!(line.len(), template.len())). Using an impossible widening here risks making the scenario misleading and brittle if future validation is added. Prefer a widening that keeps token count constant (e.g. widen the logged token at position 2).

This issue also appears in the following locations of the same file:

• line 232
• line 256

            // A real widening: v2 gains a trailing wildcard, so the
            // version's tokens differ from v1's and key separately.
            AuditEvent {
                tenant_id: TenantId::new("t"),
                timestamp: at(TS0 + 3),
                payload: AuditPayload::Template {
                    template_id: 2,
                    triggering_line_hash: hash_triggering_line(b"widen"),
                    triggering_line_sample: None,
                    change: TemplateChange::Widened {
                        old_version: 1,
                        new_version: 2,
                        old_template: "user <*> logged in from <*>".to_owned(),
                        new_template: "user <*> logged in from <*> <*>".to_owned(),
                        positions_widened: vec![6],
                    },