Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SDK] Add a test covering exception thrown in custom sampler #4072

Merged
merged 4 commits into from
Jan 23, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions test/OpenTelemetry.Tests/Trace/SamplersTest.cs
Original file line number Diff line number Diff line change
Expand Up @@ -252,5 +252,30 @@ public void SamplersDoesNotImpactTraceStateWhenUsingNull(SamplingDecision sampli
Assert.Equal(parentTraceState, activity.TraceStateString);
}
}

[Fact]
public void SamplerExceptionBubblesUpTest()
{
// Note: This test verifies there is NO try/catch around sampling
// and it will throw. For the discussion behind this see:
// https://github.com/open-telemetry/opentelemetry-dotnet/pull/4072

var activitySourceName = Utils.GetCurrentMethodName();
using var activitySource = new ActivitySource(activitySourceName);
using var tracerProvider = Sdk.CreateTracerProviderBuilder()
.AddSource(activitySourceName)
.SetSampler(new ThrowingSampler())
.Build();

Assert.Throws<InvalidOperationException>(() => activitySource.StartActivity("ThrowingSampler"));
}

private sealed class ThrowingSampler : Sampler
{
public override SamplingResult ShouldSample(in SamplingParameters samplingParameters)
{
throw new InvalidOperationException("ThrowingSampler");
Copy link
Contributor

@utpilla utpilla Jan 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the direction about who is responsible for catching/ not throwing the exception should come from the spec. Similar to how they have specified it for Processor OnStart and OnEnd methods here.

If we have a particular preference, we should try to get the spec updated for ShouldSample first.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the direction about who is responsible for catching the exception should come from the spec. Similar to how they have specified it for Processor OnStart and OnEnd methods here

The spec doesn't seem to talk about who should be responsible if exception was thrown from a Processor's OnStart/OnEnd?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OnEnd is called after a span is ended (i.e., the end timestamp is already set). This method MUST be called synchronously within the Span.End() API, therefore it should not block or throw an exception.

I interpret this statement as "Processor.OnEnd should not throw an exception" which makes it the user's responsibility to provide a spec-compliant processor to the SDK. If the processor logic can throw an exception, it's the user's responsibility to ensure that it is not thrown (they could simply wrap a try-catch around their processor logic.

}
}
}
}