It's difficult to write a test that reliably reproduces the IndexError as it is heavily dependent on the timing of the profiler thread. But I was able to reproduce the exact error locally a few times to verify the scenario in which it occurs and that this should fix it.

Codecov Report

Attention: Patch coverage is 92.30769% with 1 line in your changes missing coverage. Please review.

Project coverage is 80.65%. Comparing base (3f9acc4) to head (d682568).
Report is 1 commits behind head on master.

✅ All tests successful. No failed tests found.

@@            Coverage Diff             @@
##           master    #4497      +/-   ##
==========================================
+ Coverage   80.57%   80.65%   +0.07%     
==========================================
  Files         142      142              
  Lines       16051    16057       +6     
  Branches     2747     2748       +1     
==========================================
+ Hits        12933    12950      +17     
+ Misses       2248     2239       -9     
+ Partials      870      868       -2     

For visibility, reproducing the issue requires the following when using lifecycle="trace"

1. start a transaction and let it end
2. let the profiler run for exactly 1 more iteration where it triggers the shutdown
3. wait until just before the sleep of the current iteration finishes and start another transaction
4. a new profiler is started by 3 and the old profiler doesn't successfully exit, and by waiting until just before the sleep is over, the new profiler runs at almost the same time as the old profiler
5. start a bunch of transactions, they will all be queued for profiling and because there are 2 profilers concurrently popping from the deque, you'll get the IndexError