tracing_subscriber::Registry misbehaves when exiting span while some other subscriber is default

[lilyball]

Bug Report

Version

asdf-tracing v0.1.0 (/Users/lily/Dev/Scratch/asdf-tracing)
├── tracing v0.1.29
│   ├── tracing-attributes v0.1.18 (proc-macro)
│   └── tracing-core v0.1.21
└── tracing-subscriber v0.2.25
    ├── tracing v0.1.29 (*)
    ├── tracing-core v0.1.21 (*)
    ├── tracing-log v0.1.2
    │   └── tracing-core v0.1.21 (*)
    └── tracing-serde v0.1.2
        └── tracing-core v0.1.21 (*)

Platform

Darwin DeerBook 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64

Crates

tracing-subscriber

Description

If I exit a span created from something using Registry (such as FmtSubscriber) while its associated dispatch is not the default dispatch, Registry will ask the default dispatch to try_close() the span id. This means it's asking the wrong dispatch to close it, which can lead to panics.

Reproduction

let outer = tracing_subscriber::fmt().set_default();
let one = info_span!("one").entered();
let inner = tracing_subscriber::fmt().set_default();
let two = info_span!("two").entered();
drop(one); // this closes span two
drop(two); // this panics

thread 'main' panicked at 'tried to drop a ref to Id(1), but no such span exists!', /Users/lily/.cargo/registry/src/github.com-1ecc6299db9ec823/tracing-subscriber-0.2.25/src/registry/sharded.rs:346:21

[hawkw]

The neatest solution to this is probably just to change the Registry type to not need to get the current default dispatch in try_close...which I started experimenting with in #1505. Unfortunately, this requires some API changes, and introduces a few new issues I haven't quite had the time to work out.

Another option is to change the Span type to set its Dispatch as the default for the duration of the try_close call, but this seems like an unfortunate perf hit...

[lilyball]

Setting Dispatch as the default also will hit #1655 if we're in a get_default() closure.

[juchiast]

Is there any update on this?