opentelemetry-erlang-contrib icon indicating copy to clipboard operation
opentelemetry-erlang-contrib copied to clipboard

Add tests and tweak behavior of opentelemetry_req

Open andrewhr opened this issue 2 years ago • 3 comments

The main objective of this patch is to add few tests to cover main points of how this library handles OpenTelemetry.

As by-product of those tests, few tweaks were done to production code. More specifically, how we handle :path_params validation.

:path_params only has restrictions when used for span names, due constraints of "span names should never be unbounded". As such, when we set :span_name with a custom one, the check is skipped.

Another change is how :no_path_params imply: here, I understand that we as library users are asserting that "I comply and abide this path has no dynamic parts", and as such, it's safe to just use it instead of fallback to only METHOD. Otherwise, we would need some workaround like set empty :path_params just to ensure "safe" paths are reported correctly on span names.

I've considered addting Yet Another Option for "I don't want any path inference" that disables check and set span names just as METHOD, but refrain to do so here to not deviate too much from current implementation.

andrewhr avatar Aug 21 '23 11:08 andrewhr

cc @wojtekmach, as I just realized you have some patches in the works when I was prep this for publication. Let me know if there are any conflicts and I'm happy to fix them here.

andrewhr avatar Aug 21 '23 11:08 andrewhr

"I comply and abide this path has no dynamic parts", and as such, it's safe to just use it instead of fallback to only METHOD.

The fallback is just whatever the path is in the request, not method. Maybe that changes with 1.20+ spec but until then the behavior is just to use the path, e.g. /api/users

bryannaegele avatar Aug 21 '23 16:08 bryannaegele

"I comply and abide this path has no dynamic parts", and as such, it's safe to just use it instead of fallback to only METHOD.

The fallback is just whatever the path is in the request, not method. Maybe that changes with 1.20+ spec but until then the behavior is just to use the path, e.g. /api/users

I dug back through the history and as of 1.17 the format was HTTP {METHOD_NAME} for clients, so let's revert to that until the opt-in breaking changes semconv is implemented.

bryannaegele avatar Sep 05 '23 15:09 bryannaegele