Skip to content

Add shutdown method to samplers #5713

Open

Description

@tammy-baylis-swi

Is your feature request related to a problem?

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:

Describe alternatives you've considered

No response

Additional Context

No response

Would you like to implement a fix?

None

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.

Activity

  1. Mayukhga83 commented on Oct 3, 2026

    @Mayukhga83

    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.

  2. hectorhdzg commented on Oct 5, 2026

    @hectorhdzg
    Member

    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

  3. Mayukhga83 commented on Oct 5, 2026

    @Mayukhga83

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Fields

    Priority

    None yet

    Start date

    None yet

    Target date

    None yet

    Effort

    None yet

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions