panicked at 'called `Option::unwrap()` about loom HOT 4 CLOSED

Note that the second panic message begins with:

thread 'trigger::loom_tests::test_loom_sender_trigger' panicked at 'deadlock; threads = [(Id(0), Blocked(Location(None))), (Id(1), Terminated)]', /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/loom-0.7.0/src/rt/execution.rs:216:13

This indicates thatloom panicked due to a deadlock in the code under test: either a bug in your code, or in your test.

After this panic occurred, a double-panic occurred while unwinding. This often happens when a Drop impl does something that requires accessing the loom test execution state, but the test context has already been torn down. This is kind of an annoying rough edge when using loom --- we should probably spend some time ensuring that loom's simulated atomics and synchronization primitives behave more gracefully when used in a Drop impl during a panic. That would likely require some effort though.

from loom.

The double panic is kind of a loom issue, but it's occurring due to a panic from loom correctly detecting a deadlock in your test. So, loom found an issue in your code, and we should fix the double panic so that loom can report these errors better and make them easier to debug :)

from loom.

Ok for now going to close the issue then. I haven't found the reason yet, but so far the theory from your end is that it is anyway on my end (whether in the test or actual code). So going to not botter your time more here in that case. If it does end up be a loom issue I'll re-open, but so far it doesn't seem like it is. Thanks!

from loom.

Yes I did find the issue in the meanwhile. Turns out I was having a race condition that loom detected which caused me to never wake up... Gosh. Good that i start using loom for these very core primitives of my crate.

from loom.