feat(templated_uri)!: rename unredacted macro attribute into bypass_redaction

[Vaiz]

Renames the redaction-suppression attribute from #[unredacted] / unredacted to #[bypass_redaction] / bypass_redaction across the templated_uri macro API.

The new name is intentionally more explicit and slightly more "annoying" to type. This is by design: bypassing redaction is a deliberate, security-relevant choice that should stand out at the call site and prompt the author to think twice before using it. unredacted reads as a passive description of state; bypass_redaction reads as an active decision.

Migration

// Before
#[templated(template = "/{org_id}/user/{user_id}/", unredacted)]
struct UserPath { ... }

// After
#[templated(template = "/{org_id}/user/{user_id}/", bypass_redaction)]
struct UserPath { ... }

[martintmk]

why not just no_redaction?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.0%. Comparing base (ade63e3) to head (a7e807b).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #390   +/-   ##
=======================================
  Coverage   100.0%   100.0%           
=======================================
  Files         224      224           
  Lines       16187    16187           
=======================================
  Hits        16187    16187           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Vaiz]

why not just no_redaction?

it's less descriptive, and less annoying
we want to be annoying when data doesn't have proper taxonomy

[Copilot]

Pull request overview

This PR performs a breaking rename in the templated_uri macro API, changing the redaction-suppression attribute from unredacted to the more explicit bypass_redaction across macro parsing, documentation, examples, and downstream usage.

Changes:

• Renamed struct-level macro flag unredacted to bypass_redaction in templated_uri proc-macro parsing and codegen.
• Renamed field-level standalone attribute #[unredacted] to #[bypass_redaction] (and updated tests/UI fixtures accordingly).
• Updated crate docs, README, examples, and dependent crate docs/tests to use the new attribute name.

Reviewed changes

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

Show a summary per file

File	Description
crates/templated_uri_macros_impl/src/struct_template.rs	Updates macro option/field parsing and redacted-display generation to use bypass_redaction.
crates/templated_uri_macros_impl/src/lib.rs	Updates attribute filtering and macro tests to reflect the renamed flag/attribute.
crates/templated_uri/tests/ui/string_in_restricted_position.rs	Updates UI test input to use bypass_redaction.
crates/templated_uri/tests/templated_uri.rs	Updates integration tests and assertions/comments to use bypass_redaction.
crates/templated_uri/src/uri.rs	Updates doc example to the new attribute name.
crates/templated_uri/src/templated.rs	Updates trait docs/examples for field- and struct-level usage.
crates/templated_uri/src/macros.rs	Updates macro documentation describing how to bypass redaction.
crates/templated_uri/src/lib.rs	Updates crate-level docs/examples for the renamed attribute.
crates/templated_uri/examples/uri_templating.rs	Updates example usage to bypass_redaction.
crates/templated_uri/examples/classified_templating.rs	Updates example field attribute to #[bypass_redaction].
crates/templated_uri/README.md	Regenerates README content to reflect the renamed attribute.
crates/http_extensions/src/extensions/extensions_ext.rs	Updates dependent crate test usage of templated_uri macro.
crates/http_extensions/src/_documentation/recipes.rs	Updates dependent crate documentation example usage.

---

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

[kate-shine]

On the topic of name, maybe disable_redaction feels better to me, but it's an improvement either way, thanks!

[kate-shine]

maybe consider disable_redaction, but that's all :)

[Vaiz]

On the topic of name, maybe disable_redaction feels better to me, but it's an improvement either way, thanks!

personally, I like bypass_redaction more. Let's wait for other people to chime in.

[ralfbiedert]

This should be aligned with data privacy and the annotations used there, we don't want each crate to define their own terminology for opting out of redaction handling.

[Vaiz]

This should be aligned with data privacy and the annotations used there, we don't want each crate to define their own terminology for opting out of redaction handling.

applied the same change to data_privacy crate

[ralfbiedert]

applied the same change to data_privacy crate

Sorry, my point was not that you should rename data_privacy, but that you shouldn't change this away from what data_privacy has. Many of our identifiers are too long already, and we rather want to shorten them.

I also don't buy the premise. If bypass_redaction is 'safer' than unredacted because it's longer, why stop there? Why not make it could_be_dangerous_if_not_properly_applied_bypass_redaction? Rust, for much more dangerous operations, goes with unsafe. I would argue (un)redacted carries similar semantics to (un)safe in the privacy space.

[martintmk]

I have the same feeling as Ralf, I don't see that much added value of bypass_redaction vs unredacted either.

[Vaiz]

applied the same change to data_privacy crate

Sorry, my point was not that you should rename data_privacy, but that you shouldn't change this away from what data_privacy has. Many of our identifiers are too long already, and we rather want to shorten them.

I also don't buy the premise. If bypass_redaction is 'safer' than unredacted because it's longer, why stop there? Why not make it could_be_dangerous_if_not_properly_applied_bypass_redaction? Rust, for much more dangerous operations, goes with unsafe. I would argue (un)redacted carries similar semantics to (un)safe in the privacy space.

the initial complaint about unredacted was that it's not clear what it means, and bypass_redaction is more self-explanatory

the original message from Sander

"unredacted" is hard to parse - does it mean "undo redaction"? does it mean the data must be "unredact"'ed by the caller somehow?

Better would be to phrase it in a positive way. Some options:

public_data - clearly expressing that the data can be made available publicly
no_redaction - expresses the positive act of disabling redaction, removing ambiguity of "un" anything. I recognize that a "no" thing being called a positive expresison is a bit confusing so maybe the next optio is eve more clear
bypass_redaction - another variant