Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Invalid transaction names in OTEL Java agent when using Tapir + Akka Http #4343

Open
Matzz opened this issue Feb 14, 2025 · 3 comments

Comments

@Matzz
Copy link
Contributor

Matzz commented Feb 14, 2025

Tapir version: "1.11.13"
OTEL Java agent version: "2.11.0"
Scala version: "2.13.16"

Describe the bug

When using Tapir + Akka Http, OTEL Java agent sets the wrong transaction names. Only request method is included without url template.
Plain Akka Http routes provides correct transaction names.

How to reproduce?
Here is a sample application which depicts this issue. All steps to reproduce are described in README
https://github.com/Matzz/tapir-test/blob/main/README.md

@adamw
Copy link
Member

adamw commented Feb 19, 2025

I'm not that familiar with OTEL Java Agent, probably it has some Akka-specific instrumentation code. To work with Tapir, it would need to have Tapir-specific instrumentation code.

Alternatively, we could try to generate Akka directives (in the tapir -> akka interpreter) which can be instrumented using the Java Agent, but for that, we would need details on how this instrumentation works

@masonedmison
Copy link

Hi @adamw I work with @Matzz, and we have been looking at this issue together. So it looks like the java agent computes the URI as part of this code. From what I can tell, tapir uses a more general mechanism to match the route (in FilterServerEndpoints?). Perhaps there could be an opportunity to use PatchMatcher when computing the path within PekkoServerRequest?

@adamw
Copy link
Member

adamw commented Feb 20, 2025

Thinking a bit more about this, I don't think we'll be able to use Akka/Pekko's mechanisms for path matching. Tapir uses a different approach, with path decoders that are defined as part of the inputs, and while translating this to path matchers would be in theory possible, it would be a lot of work. Probably much easier to add OTel/Tapir integration - e.g. through an interceptor (not "magical", just a simple interceptor), which would report the appropriate data when an endpoint is successfully decoded.

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

No branches or pull requests

3 participants