[bug] Rare but deadly computational bug in TraceIdRatioBasedSampler

[ArtemSerostanov]

Package

OpenTelemetry

Package Version

Package Name	Version
OpenTelemetry	1.15.0

Runtime Version

net10.0

Description

Unfortunately, I was unable to compile the source code locally, so I'm filing an issue instead of a full-blown pull request.

The problem

TraceIdRatioBasedSampler makes a decision on whether to sample a trace or not by converting a trace id to a long value and then comparing this value to lower and upper boundaries. However, the process of converting a trace id to long is bugged.
More specifically, the call Math.Abs(GetLowerLong(traceIdBytes) throws if GetLowerLong returns long.MinValue. It's impossible to get an absolute value of long.MinValue because the corresponding positive value is bigger then long.MaxValue.

While I understand that this problem is very rare (one has to generate a trace id that converts exactly to long.MinValue), the consequences are fatal. Throwing an exception from a sampler essentially discard the entire http request.

The solution

Implement a "safe" Math.Min equivalent like this:

    private static long SafeAbs(long value)
    {
        if (value == long.MinValue)
        {
            return long.MaxValue;
        }
        else
        {
            return Math.Abs(value);
        }
    }

Steps to Reproduce

• Create a mock trace id generator that generates trace ids that convert to long.MinValue
• Feed these trace ids to TraceIdRatioBasedSampler

Expected Result

TraceIdRatioBasedSampler should never throw regardless of which trace id is being sampled

Actual Result

System.OverflowException: Negating the minimum value of a twos complement number is invalid.

Additional Context

No response

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[martincostello]

Unfortunately, I was unable to compile the source code locally

In what way?

[Iceshen87]

Hi OpenTelemetry team! 👋

Issue Analysis:
Rare computational bug in TraceId suggests an edge case in the trace ID generation or validation logic.

Investigation Plan:

1. Review TraceId generation code
2. Identify edge cases in computational logic
3. Add proper boundary checks
4. Create reproduction test case
5. Fix and add regression tests

Timeline: 3-4 days
Budget: Open to discussion

Why I am a good fit:

• Distributed tracing experience
• Strong .NET/C# background
• Experience with edge case debugging

Happy to investigate this rare bug!

• Ethan (Iceshen87)

[martincostello]

Budget: Open to discussion

There is no financial compensation for contributing to this repository.

Assuming you're a human and not an LLM, feel free to investigate the issue and propose a fix.