Failing specs on fresh install of `rails-dev-box`

A May Of WTFs
1

I recently installed the Rails framework repo by following the instructions here. I read in the Rails Guides link here that it’s more common to individually run the specs for each Rails component (i.e. ActiveRecord, ActiveJob, etc.).

To get a baseline / sanity check, I ran the specs in each of those sub-folders. In the ActiveStorage folder, my results after the first test run were 365 runs, 884 assertions, 7 failures, 34 errors, 7 skips. After the 2nd attempt, the results were 365 runs, 783 assertions, 8 failures, 55 errors, 7 skips. I think posting all errors and failures here would be overly verbose, but I’m happy to do so upon request.

That said, the vast majority of errors referenced either Could not open library 'vips.so.42', ActiveStorage::Blob is marked for strict_loading, or ActiveStorage::Attachment is marked for strict_loading. Two examples w/ stack traces:

// 1.
bin/test test/controllers/representations/redirect_controller_test.rb:11
Error:
ActiveStorage::Representations::RedirectControllerWithVariantsTest#test_showing_variant_inline:
LoadError: Could not open library 'vips.so.42': vips.so.42: cannot open shared object file: No such file or directory.
    /var/lib/gems/2.7.0/gems/ffi-1.15.3/lib/ffi/library.rb:145:in `block in ffi_lib'
    /var/lib/gems/2.7.0/gems/ffi-1.15.3/lib/ffi/library.rb:99:in `map'
    /var/lib/gems/2.7.0/gems/ffi-1.15.3/lib/ffi/library.rb:99:in `ffi_lib'
    /var/lib/gems/2.7.0/gems/ruby-vips-2.1.2/lib/vips.rb:573:in `<module:Vips>'
    /var/lib/gems/2.7.0/gems/ruby-vips-2.1.2/lib/vips.rb:570:in `<top (required)>'
    /var/lib/gems/2.7.0/gems/zeitwerk-2.4.2/lib/zeitwerk/kernel.rb:34:in `require'
    /var/lib/gems/2.7.0/gems/zeitwerk-2.4.2/lib/zeitwerk/kernel.rb:34:in `require'

// 2. 
bin/test test/controllers/representations/proxy_controller_test.rb:72
Error:
ActiveStorage::Representations::ProxyControllerWithPreviewsTest#test_showing_preview_inline:
ActiveRecord::StrictLoadingViolationError: `ActiveStorage::Attachment` is marked for strict_loading. The `ActiveStorage::Blob` association named `:blob` cannot be lazily loaded.
    /vagrant/rails/activerecord/lib/active_record/core.rb:248:in `strict_loading_violation!'
    /vagrant/rails/activerecord/lib/active_record/associations/association.rb:226:in `find_target'
    /vagrant/rails/activerecord/lib/active_record/associations/singular_association.rb:44:in `find_target'
    /vagrant/rails/activerecord/lib/active_record/associations/association.rb:179:in `load_target'
    /vagrant/rails/activerecord/lib/active_record/associations/association.rb:68:in `reload'
    /vagrant/rails/activerecord/lib/active_record/associations/singular_association.rb:11:in `reader'

And in the ActiveJob directory, I observed 378 runs, 785 assertions, 0 failures, 14 errors, 27 skips, with the following example error being representative of all of the failing specs:

Error:
QueuingTest#test_should_run_job_with_higher_priority_first:
NoMethodError: undefined method `adapter_is?' for #<QueuingTest:0x0000557c3e1026f0>
    /vagrant/rails/activejob/test/integration/queuing_test.rb:126:in `block in <class:QueuingTest>'

For the ActiveJob failures, I do see def adapter_is? defined in activejob/test/support/integration/test_case_helpers.rb, and this file is imported into activejob/test/support/integration/helper.rb, but helper.rb is loaded into the specfile via require "helper", and I don’t see activejob/test/support/integration/ anywhere in the $LOAD_PATH when I print it out during a spec run. I’d be stoked to contribute my first Rails PR, so if changing require "helper" to require_relative ../support/integration/helper is helpful then I can spin up that PR pretty quickly. I did try this and it does seem to be a net win with an updated result of 378 runs, 777 assertions, 2 failures, 1 errors, 40 skips, although clearly it’s not the only underlying issue.

As a noob Rails contributor, I guess I’m initially wondering if these failures indicate that I made a mistake during setup, or if this is a known issue of some sort? After some Googling of these errors, I didn’t find any reports of similar errors, so I’m guessing the mistake lies with me. But I’d be curious if others have encountered a similar issue on their side.

EDIT: At the risk of being presumptuous, I created a GitHub issue here and PR here.

2

Thanks, fixed in Install libvips · rails/rails-dev-box@d3eaf8a · GitHub.

You can sudo apt-get install libvips in your current box (no password required), or git pull + vagrant destroy + vagrant up.

In the future, it is better to report something like this in the rails/rails-dev-box project itself.

1 Like