Description
Current behaviour
Options keyword arguments are not being respected when trying to integrate and modify Net/HTTP and Faraday instrumentation.
When attempting to supply a range of error_status_codes
into Datadog.configure_onto(client, **options)
via a block the range is not being applied, all error_status_codes are still traced as errors which is the default behaviour. This is the same for other options keywords as well.
For error_status_codes specifically, we believe the issue is here:
For some reason request[:options] does not contain the error codes/ranges we provide.
Expected behaviour
Options keyword arguments to be respected when instrumenting Net/HTTP or Faraday on a per-connection basis as defined in the docs https://docs.datadoghq.com/tracing/trace_collection/automatic_instrumentation/dd_libraries/ruby/#nethttp
Steps to reproduce
Attempt to define a Faraday connection through a build method like below:
def build(&block)
new(
Faraday.new do |builder|
block&.call(builder)
end,
)
end
When the build method is called, pass in a block like below:
do |builder|
builder.adapter(:net_http) do | http |
Datadog.configure_onto(http, {error_status_codes: [400..403]})
end
end
Note options keyword arguments aren't applied to the http connection.
How does datadog
help you?
Environment
- datadog version:
2.4.0
- **Configuration block (
Datadog.configure ...
): **
Datadog.configure do |c|
c.tracing.instrument(:http, service_name: 'api-http')
c.tracing.instrument(:faraday, service_name: 'api-faraday')
end
- Ruby version:
3.2.4
- Operating system:
Linux - Relevant library versions:
faraday (2.9.0)
faraday-net_http (>= 2.0, < 3.2)
faraday-net_http (3.1.0)
net-http