I18n::InvalidLocaleData: can not load translations from /Users/me/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/faker-2.2.0/lib/locales/en/star_trek.yml: #<Errno::ENOENT: No such file or directory - bs_fetch:atomic_write_cache_file:chmod>

[joshuapinter]

We're seeing an intermittent issue arise when running test in parallel using parallel_tests on Rails 5. It occurs every few test suite runs.

The error is something like this:

I18n::InvalidLocaleData:
  can not load translations from /Users/me/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/faker-2.2.0/lib/locales/en/star_trek.yml: #<Errno::ENOENT: No such file or directory - bs_fetch:atomic_write_cache_file:chmod>
# ./spec/spec_helper.rb:70:in `block (2 levels) in <top (required)>'
# ./spec/spec_helper.rb:70:in `each'
# ./spec/spec_helper.rb:70:in `block in <top (required)>'
# ./spec/spec_helper.rb:67:in `<top (required)>'
# ------------------
# --- Caused by: ---
# Errno::ENOENT:
#   No such file or directory - bs_fetch:atomic_write_cache_file:chmod

The error is either bs_fetch:atomic_write_cache_file:chmod or bs_fetch:atomic_write_cache_file:rename.

The actual file is not always the same but it is always a translation file from the faker gem, like the star_trek.yml one shown above.

For some additional context:

• We use the faker gem in some of test seeds/Factories in order to generate randomized data.
• Initially, we were loading faker in the Gemfile with just gem "faker" but were seeing these errors at the start of our test suite when our databases were being created and setup.
• We tried not requiring it in the Gemfile with gem "faker", require: false and requiring it manually in the seeds/Factories where it is used.
• This appeared to just move the errors from the start of the test suite to a little later on when those seeds/Factories are loaded and used.
• We are running this on a 24-thread Mac Pro, so there are 24 test runners.
• We have never seen this on machines with less thread counts (MacBook Pro, Mac Mini, etc.).

I've seen both #177 and #262 as very similar issues, but they both involve the use of Docker.

We are not using Docker at all.

I'm not entirely sure what the ideal solution is here but perhaps just having the ability to exclude certain Gems/files from Bootsnap so we don't run into these types of issues.

But I wanted to make sure to report it here as a new issue because it is not Docker related and it can be reproduced and should be fixable.

If bootsnap wasn't so great, we would just disable it, but the performance gains of bootsnap, especially when running tests in parallel with lots of runners, is significant (30%) so we want to get this fixed.

Thanks. Over to you.

[casperisfine]

it can be reproduced

Would you be willing to craft a reproduction script? e.g. a clean new Rails app, with maybe lots of autogenerated tests?

If you manage to reproduce this semi-reliably, I'm willing to put the necessary work to get this solved.

[joshuapinter]

@casperisfine Thanks for the lightning quick response! Yes, I'll meet you half way with that for sure. It may take some time as things (as always) are busy. But I'll see what I can do to reproduce it on a clean Rails install and let you know.

[casperisfine]

Closing as duplicate of #353

We're currently experimenting with a fix there.

[joshuapinter]

Yup, thanks. Looks like the fix is working so I'll follow-up on #353. Cheers.