Client-side Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_leg

We got a driveby log barf from a cypherpunks:

TorProvider: [Tor warning] Bug: Tor 0.4.8.7 (git-bf5e234d): Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed in conflux_pick_first_leg at conflux.c:565. (Stack trace not available) (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
TorProvider: [Tor warning] conflux_pick_first_leg: Bug: Matching client sets: (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
TorProvider: [Tor warning] conflux_log_set: Bug: Conflux 6EB994986FCDAA7A: 0 linked, 0 launched. Delivered: 692335; teardown: 0; Current: 0000000000000000, Previous: 0000000000000000 (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
TorProvider: [Tor warning] conflux_pick_first_leg: Bug: Matching server sets: (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
TorProvider: [Tor warning] conflux_log_set: Bug: Conflux 6EB994986FCDAA7A: 0 linked, 0 launched. Delivered: 692335; teardown: 0; Current: 0000000000000000, Previous: 0000000000000000 (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
TorProvider: [Tor warning] conflux_pick_first_leg: Bug: End conflux set dump (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
TorProvider: [Tor warning] circuit_get_package_window: Bug: Conflux has no circuit to send on. Circuit 000001896a32af00 idx 5 marked at line circuitlist.c:1693 (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936
TorProvider: [Tor warning] tor_bug_occurred_: Bug: conflux.c:565: conflux_pick_first_leg: Non-fatal assertion !(smartlist_len(cfx->legs) <= 0) failed. (on Tor 0.4.8.7 bf5e234d) TorProvider.sys.mjs:936

This looks like a client-side issue. The strange thing is that unlike #40842 (closed), this is client-side (Tor Browser, I believe). Additionally, in_full_teardown is false, but both the curr_leg and the prev_leg are NULL, and the set was previously used to receive a bunch of data (delivered 692335 cells, as the log says).

The mark for close line is in circuit_unlink_all_from_channel().

What I think might be happening is some kind of shutdown race, where the curr_leg is quickly nulled out via linked_circuit_free() (which does not set in_full_teardown -- this could be a bug), but the prev_leg is still going through the channel teardown path and getting marked first, and then hitting this situation, without in_full_teardown set.

Other than shutdown, I can't think of any other ways that the curr_leg could get all the way freed and NULL, without setting in_full_teardown. I suppose it is also possible that there were previous warn logs related to this that they omitted.

Unfortunately, the cypherpunk disappeared, and we have no idea if their Tor Browser was having connectivity issues, or if they restarted their Tor, or what else might be a factor.

So we need another instance from a helpful reporter. Ideally one that also has a backtrace (I think this must be windows, because the backtrace is missing).