Skip to content

feat: endpoint renaming#260

Merged
cataphract merged 7 commits intomainfrom
glopes/endpoint-renaming
Nov 19, 2025
Merged

feat: endpoint renaming#260
cataphract merged 7 commits intomainfrom
glopes/endpoint-renaming

Conversation

@cataphract
Copy link
Contributor

@cataphract cataphract commented Nov 3, 2025

Description

Implements RFC-1051: APM endpoint resource renaming

Motivation

Additional Notes

Jira ticket: APPSEC-58791

@cataphract cataphract requested a review from a team as a code owner November 3, 2025 16:50
@cataphract cataphract requested review from zacharycmontoya and removed request for a team November 3, 2025 16:50
@cataphract cataphract changed the title Glopes/endpoint renaming Endpoint renaming Nov 4, 2025
@cataphract cataphract force-pushed the glopes/endpoint-renaming branch from b352e56 to 251dfa6 Compare November 4, 2025 09:26
@pr-commenter
Copy link

pr-commenter bot commented Nov 4, 2025

Benchmarks

Benchmark execution time: 2025-11-18 18:58:26

Comparing candidate commit 849fddb in PR branch glopes/endpoint-renaming with baseline commit 8d9d6ba in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 1 metrics, 0 unstable metrics.

REQUIRE(span.tags.count(tags::http_endpoint) == 0);
}

SECTION("pre-existing http.endpoint is preserved") {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this behavior mandated by the RFC and/or enforced by other tracers? I don't see this described anywhere

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The RFC is silent on this. While http.endpoint should not be provided the user (unlike http.route, which may be), this option made most sense to me (maybe the value was already calculated/cached)


// is_str requires a special char or a size >= 20
viable_components &= ~component_type::is_str |
bool2mask(found_special_char || (path.size() >= 20));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

super small nit: Can we refactor into if statements to get rid of the bool2mask operation?

found_special_char = true;
viable_components &=
~(component_type::is_int | component_type::is_int_id |
component_type::is_hex | component_type::is_hex_id);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why you'd want continue after this point as there is no condition in which you remove strings as a viable component within the for loop and you've removed all other possibilities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants