CarrierWave in test does not delete file

[coding-bunny]

Hello,

I'm currently upgrading CarrierWave as part of our Rails upgrade process, and noticed a change in behavior when jumpin on the master branch to resolve all deprecation warnings for Rails.

We basically had a test, where we call delete on a File stored with CarrierWave, and this method returns true in our testing environment.
Yet when we ask whether the file still exists, the method also returns true where this used to return false before.

Did something got changed in the way CarrierWave works in testing environments?

The test in question:

describe '#delete' do
   it 'deletes a file' do
     expect(s3_file).to exist
     s3_file.delete
     expect(s3_file).not_to exist
  end
end

This is part of our S3 Uploader spec, and it worked fine in Rails 5.0 with CarrierWave 1.2

[mshibuya]

Could you tell me the last working version of CarrierWave?

[coding-bunny]

According our Gemfile that would have been 1.0.0

[mshibuya]

Do you run tests with transactional fixtures? CarrierWave's file operation is supposed to be run in transactional manner.
cf. #2209

[coding-bunny]

We don't run transactional fixtures.
Not sure if I can even enable that at this point in the project, or rather not sure what the consequences will be. But if that solves the problem, might be worth a try I suppose.

[coding-bunny]

I've enabled transactional fixtures, but the test still fails :

expected #<ShardedS3Storage::File:0x0055a7993f7730 @uploader=#<CategoryImageUploader:0x0055a799455e48 @model=#...rage_class=nil,
    encryption=nil,
    encryption_key=nil,
    version=nil,
    kms_key_id=nil
  >> not to exist

  0) ShardedS3Storage File interacting with S3 #delete deletes a file
     Failure/Error: expect(s3_file).not_to exist

       expected #<ShardedS3Storage::File:0x0055a7993f7730 @uploader=#<CategoryImageUploader:0x0055a799455e48 @model=#...rage_class=nil,
           encryption=nil,
           encryption_key=nil,
           version=nil,
           kms_key_id=nil
         >> not to exist
     # ./spec/storages/sharded_s3_storage_spec.rb:133:in `block (5 levels) in <top (required)>'
     # ./spec/rails_helper.rb:84:in `block (3 levels) in <top (required)>'
     # /home/olivar/.rvm/gems/ruby-2.3.0/gems/database_cleaner-1.7.0/lib/database_cleaner/generic/base.rb:16:in `cleaning'
     # /home/olivar/.rvm/gems/ruby-2.3.0/gems/database_cleaner-1.7.0/lib/database_cleaner/base.rb:100:in `cleaning'
     # /home/olivar/.rvm/gems/ruby-2.3.0/gems/database_cleaner-1.7.0/lib/database_cleaner/configuration.rb:86:in `block (2 levels) in cleaning'
     # /home/olivar/.rvm/gems/ruby-2.3.0/gems/database_cleaner-1.7.0/lib/database_cleaner/configuration.rb:87:in `cleaning'
     # ./spec/rails_helper.rb:83:in `block (2 levels) in <top (required)>'

17 examples, 1 failure, 16 passed

[mshibuya]

Can you reproduce this problem using fresh Rails app?
Uploading it to Gist or GitHub repo may help track down the issue.

[coding-bunny]

I can try setting this up when I find some free time for this...

[coding-bunny]

https://github.com/coding-bunny/carrierwave-test

All required information is inside the project's README

[mshibuya]

Ah I see, it was because of the change in bffbaaf.
I've just pushed a fix as f94b061.

Thanks for reporting!

[coding-bunny]

Thank you for fixing it :D

[coding-bunny]

minor side question : Will a separate release go out for this "soonish", we're trying to avoid pointing to master branch with gems.

[mshibuya]

The fix will be included in upcoming release of 2.0.0, which I hope will be in June or so...

[mriddle]

This issue was fixed in 2.0.0 (f94b061) but remains in 1.3.2 and should probably be backported if there's a plan to continue support for the 1.x series.