Add way to prevent expected exceptions from being recorded as errors in open telemetry spans

[DavidRigglemanININ]

Describe the feature

Currently, if there is an an error like a conditional check failure (400), this appears to get recorded with span.setStatus(Status.ERROR) and it's very challenging to try to undo that. This causes us a bunch of error spam that we would love to eliminate because these are errors that are expected and not unexpected ones. I completely understand not wanting this behavior to be the default, but just some optional config to allow us to provide a list of exception classes to ignore from setting the span to an error status would be great. Or an override callback to return a desired status based on some parameters would also be acceptable

Use Case

Working with open telemetry and avoiding unnecessary error noise

Proposed Solution

At a simplest level, just allowing us to specify a list of error classes (or even fully qualified class names) would be all that is needed. I could imagine more complicated and flexible solutions that involve callbacks, but those wouldn't be strictly necessary for us.

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS Java SDK version used

2.42.38

JDK version used

21.0.10

Operating System and version

MacOS 26.5

[debora-ito]

Hi @DavidRigglemanININ thank you for reaching out.

this appears to get recorded with span.setStatus(Status.ERROR)

Can you elaborate more on how span works in this context? I'm not super familiar with open telemetry, maybe give us a code sample showing how you use it with the SDK.

This causes us a bunch of error spam that we would love to eliminate because these are errors that are expected and not unexpected ones

Can you show an example of how this looks like?

[DavidRigglemanININ]

So there's the instrumentation library for the AWS SDK (https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/aws-sdk/aws-sdk-2.2/library/README.md), and the open telemetry agent works in conjunction with this library to auto instrument our code. Hence the challenge of not having the ideal level of control we need. I do have a hack with the execution interceptor to essentially hook into an AWS client and set the status to OK before the code has a chance to set it to ERROR (because the otel spec says that if status is set to OK, future attempts to set it to ERROR will be ignored). Here's what the hack looks like

class WfmExpectedAwsErrorInterceptor : ExecutionInterceptor {
    override fun afterTransmission(
        context: Context.AfterTransmission,
        executionAttributes: ExecutionAttributes
    ) {
        val statusCode = context.httpResponse().statusCode()
        if (statusCode >= 400 && statusCode < 500) {
            // we are relying on the behavior here that once the status on a span is set to OK,
            // future attempts to set it to error (i.e. from the AWS SDK) will be ignored
            Span.current().setStatus(StatusCode.OK)
        }
    }
}

And then in my dynamo DB client code, for example, I'm doing this

        return DynamoDbClient.builder()
            .region(region)
            .endpointProvider(endpointProvider)
            .httpClientBuilder(httpClientBuilder)
            .overrideConfiguration { it.addExecutionInterceptor(WfmExpectedAwsErrorInterceptor()) }
            .build()

But what I would rather have is some way in the builder to specify ignored exceptions for instrumentation purposes or either give me a better callback hook for setting the status. There's a similar issue on the NodeJS AWS SDK side (open-telemetry/opentelemetry-js-contrib#1765), although that one seems to have more solutions now available.