You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The sampler doesn't have a shutdown method. This is a problem for any samplers that manage resources like thread pools / connections; they need to be shutdown to prevent memory leaks. A community sampler that has this issue is AwsXRayRemoteSampler.
Describe the solution you'd like
Let's add a shutdown method to the OTel Python Sampler ABC that gets called when TracerProvider is shutdown. Then, implement for AwsXRayRemoteSampler. See also:
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.
I’d be interested in taking on the core Python SDK portion of this.
My current thought is to add a default no-op shutdown() method to Sampler. That should keep this backward-compatible with existing custom sampler subclasses. They wouldn’t need to implement anything unless they actually have shutdown work to perform.
Then, TracerProvider.shutdown() could invoke the sampler’s shutdown() as part of its normal shutdown path.
A few details I’d like to clarify before implementing:
Is there a preferred shutdown ordering between the sampler and the span processors/exporters?
How should exceptions from Sampler.shutdown() be handled? Propagate them, suppress/log them, or follow the behavior of the other shutdown components?
Should shutdown() be expected to be idempotent, and should the SDK provide any protection around repeated calls?
For the AWS X-Ray sampler specifically, I’m assuming the corresponding implementation change would be better handled separately in the contrib repository rather than bundled into the SDK PR. Does that match the intended split?
If so, I’ll add focused unit tests around the sampler shutdown behavior and keep the PR narrowly scoped to the core SDK change.
The no-op default makes sense so existing samplers don't break. Should wrapper samplers like ParentBased also shut down the samplers they wrap? It would be good to test normal shutdown, shutdown when the process exits, and calling shutdown more than once
Thanks for the guidance. I’ve opened #5747 with the core SDK implementation.
The PR adds a backward-compatible no-op Sampler.shutdown() and calls it from TracerProvider.shutdown() after the span processors have been shut down.
Wrapper samplers forward the lifecycle call:
ParentBased shuts down each distinct directly wrapped sampler once.
AlwaysRecordSampler shuts down its wrapped root sampler.
TracerProvider.shutdown() is idempotent, so an explicit shutdown followed by the process-exit handler does not shut the components down twice.
The tests cover normal shutdown, automatic shutdown at process exit, repeated calls, wrapper propagation, shutdown ordering, and exception paths. Existing custom samplers without a shutdown() override remain compatible.
The AWS X-Ray sampler change will be handled separately in the contrib repository.
Activity
Mayukhga83 commentedon Oct 3, 2026
I’d be interested in taking on the core Python SDK portion of this.
My current thought is to add a default no-op
shutdown()method toSampler. That should keep this backward-compatible with existing custom sampler subclasses. They wouldn’t need to implement anything unless they actually have shutdown work to perform.Then,
TracerProvider.shutdown()could invoke the sampler’sshutdown()as part of its normal shutdown path.A few details I’d like to clarify before implementing:
Sampler.shutdown()be handled? Propagate them, suppress/log them, or follow the behavior of the other shutdown components?shutdown()be expected to be idempotent, and should the SDK provide any protection around repeated calls?For the AWS X-Ray sampler specifically, I’m assuming the corresponding implementation change would be better handled separately in the contrib repository rather than bundled into the SDK PR. Does that match the intended split?
If so, I’ll add focused unit tests around the sampler shutdown behavior and keep the PR narrowly scoped to the core SDK change.
hectorhdzg commentedon Oct 5, 2026
The no-op default makes sense so existing samplers don't break. Should wrapper samplers like
ParentBasedalso shut down the samplers they wrap? It would be good to test normal shutdown, shutdown when the process exits, and calling shutdown more than onceMayukhga83 commentedon Oct 5, 2026
Thanks for the guidance. I’ve opened #5747 with the core SDK implementation.
The PR adds a backward-compatible no-op
Sampler.shutdown()and calls it fromTracerProvider.shutdown()after the span processors have been shut down.Wrapper samplers forward the lifecycle call:
ParentBasedshuts down each distinct directly wrapped sampler once.AlwaysRecordSamplershuts down its wrapped root sampler.TracerProvider.shutdown()is idempotent, so an explicit shutdown followed by the process-exit handler does not shut the components down twice.The tests cover normal shutdown, automatic shutdown at process exit, repeated calls, wrapper propagation, shutdown ordering, and exception paths. Existing custom samplers without a
shutdown()override remain compatible.The AWS X-Ray sampler change will be handled separately in the contrib repository.