Hi there,

Thanks for reaching out!

We support configurable error codes for the http client globally via an env var: DD_TRACE_HTTP_CLIENT_ERROR_STATUSES, where specified values are considered errors, and any unspecified values are considered OK. Individual and range values are supported, e.g: DD_TRACE_HTTP_CLIENT_ERROR_STATUSES=400,402,404-410.

Can you use this option, or do you specifically need a way to configure error codes per client?

Thanks!

Hi @barp ,

In v1, we already provide this functionality via the the RTWithErrorCheck option.

Is there a specific reason this doesn’t address your use case? I’m trying to determine whether there’s a gap in the existing support or if this option might have just been overlooked.

Error check (of return value) and status checks are 2 seperate things, since error status is not considered an error the code will go to the status check in which it will always mark it as an error if it's anything between 400-500.

In shortRTWithErrorCheck doesn't work in this case as can be seen in

as can be seen that the default status check for clients is

Hi @barp ,

Thanks for the clarification, though I’m still not entirely sure I understand the issue. Are you looking to treat certain HTTP status codes (e.g., some 4xx responses) not as errors? If so, you can just exclude those codes from your error check logic.

Or, maybe you'd like the status evaluation to rely on different criteria entirely—perhaps looking at another part of the response rather than just the HTTP status?

I appreciate your patience as we sort this out. Thanks!

I'm looking to not treat all http status codes and all possible errors from a client as not errors (as in I don't want an error reported to data dog error tracking) for every single issue with a specific client I know will have errors.
I have my own custom error handling on the returned error from the client and in the current state datadog will get an error report regardless of what I do and I cannot change that no matter what I do.

this is because datadog does the error checks in the instrumentated code which I don't have control over and reports those errors no matter if I actually handle those errors. At the current state datadog will report an error even if the code that called the http.Get (for example) function handles the errors correctly.

My personal opinion is that error reporting should only happen if the calling user code (not the library code) didn't handle the error. But at the current state getting an error in Error Tracking is unavoidable in go.

I don't want to spam you guys too much, is there an update on this?
Was there any issue with my previous message?

@barp It's ok. We've decided to accept this PR in our in-progress v1.73.0 release. Please, consider rebasing this PR against the branch release-v1.73.x after adding at least a test for showing that your change is working.

@barp As we want to include this to the last v1 release, v1.73.0, and we need to dogfood it ASAP, we've created a PR based in yours against the right release branch and adding test coverage. I'm closing your PR in favour of ours #3479.