Issue with concurrent-ruby dependency under mutation testing

[mostlyobvious]

There has been a recent wave of failing builds on particular RuntimeError:

#<Thread:0x00007fab53622338@/root/project/ruby_event_store/spec/client_spec.rb:207 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
	5: from /root/project/ruby_event_store/spec/client_spec.rb:208:in `block (4 levels) in <module:RubyEventStore>'
	4: from /root/project/ruby_event_store/lib/ruby_event_store/client.rb:215:in `with_metadata'
	3: from /root/project/ruby_event_store/lib/ruby_event_store/client.rb:306:in `metadata='
	2: from /usr/local/bundle/gems/concurrent-ruby-1.1.7/lib/concurrent-ruby/concurrent/atomic/ruby_thread_local_var.rb:77:in `value='
	1: from /usr/local/bundle/gems/concurrent-ruby-1.1.7/lib/concurrent-ruby/concurrent/atomic/ruby_thread_local_var.rb:42:in `semi_sync'
/usr/local/bundle/gems/concurrent-ruby-1.1.7/lib/concurrent-ruby/concurrent/atomic/ruby_thread_local_var.rb:77:in `block in value=': can't add a new key into hash during iteration (RuntimeError)

This comes from the code that was not changed recently and uses ThreadLocalVar from concurrent-ruby package.

It has been reported [#698] in the past that particular version of that package segfaulted on MRI 2.6. As a resolution, dependency on version >= 1.1.6 was set.

There has been a new release of concurrent-ruby since August 08, 2020 (1.1.7). It has changed the implementation of ThreadLocalVar to rely on GIL on MRI to avoid problems with thread/mutex/queue in finalizers:
ruby-concurrency/concurrent-ruby@a6654b3

We've started observing the issue on CI since 2020-08-18 (and CI was not used earlier this month). There's no Gemfile.lock for dev dependencies and this new version has been pulled in.

Mutation testing with mutant is known to exercise MRI very well — I'm not surprised if it exposes some underlying MRI issues.

[pitr-ch]

I think I see the issue, I'll fix it asap in concurrent-ruby and release a new version.

[mostlyobvious]

@pitr-ch The issue seems to be gone 👍