CarrierWave not uploading (after upgrade)

Question

A month back I upgraded my Ruby version on RoR-app from 1.9.3 to 2.3.3. I have been successfully using fog & carrierwave to upload images to Amazon S3 before that but after the upgrade it stopped working. It does not upload my images to S3 any longer, the folders and files are not created there. What makes this so problematic is that I cannot troubleshoot it at all, I get no error messages or anything.

Versions:

• fog 1.38.0
• carrierwave 1.0.0
• ruby 2.3.3
• rails 4.1.13

Useful information:

• I have tried fog/aws and carrierwave-aws with the same (failing) result
• If I change the AWS credentials to something obviously false, the same problem occurs. I.e., it seems like there could be something wrong with the CarrierWave config file, or that it is not loaded or something
• The objects (Gift) are being saved properly
• I have not done any changes on Amazon, as far as I know.
• I have tried to swith to another set of AWS Access key and id but with the same problem.
• I am using AssetSync on the same app (with the same credentials) to upload to AWS and this works! I.e. there shouldn't be something wrong with AWS/S3.

initializers/carrierwave.rb

CarrierWave.configure do |config|
  config.storage = 'fog'    
  config.fog_credentials = {
    :provider               => 'AWS',
    :aws_access_key_id      => 'ABC123CODE',
    :aws_secret_access_key  => '+ABC123CODEKEY', 
    :region                 => 'eu-central-1'
  }
  config.fog_directory  = 'myapp-se'
  config.cache_dir = "#{Rails.root}/tmp"

  config.fog_attributes = {
    expires: 1.year.from_now.httpdate,
    cache_control: "max-age=#{1.year.to_i}"
  }

  config.ignore_integrity_errors = false
  config.ignore_processing_errors = false
  config.ignore_download_errors = false

end

Gift-model (gift.rb) - (related part)

  mount_uploader :cached_image, GiftImageUploader
  #validates_integrity_of :cached_image
  #validates_processing_of :cached_image  
  validates_integrity_of :cached_image
  validates_processing_of :cached_image
  validates_download_of :cached_image 

    file = Tempfile.new(["image", ".jpg"])
    file.binmode

    begin 
      open(URI.parse(external_image_url), :allow_redirections => :safe) do |data|
        file.write data.read
      end           
    rescue Exception => e
      logger.info "Error fetching image for product #{id}: " + e.message
      return false
    end

    file.rewind

    self.cached_image = file
    begin
      self.skip_callbacks = true
      if self.save!
        logger.info "Successfully cached image for product #{id}"
        return true
      else
        logger.info "Soft Error saving product #{id}"
        return false
      end        
      self.skip_callbacks = false
    rescue Exception => e
      logger.info "Rescue Error saving product #{id}" + e.message
    end

Uploader file

class GiftImageUploader < CarrierWave::Uploader::Base
  include CarrierWave::RMagick

  storage :fog

  def store_dir
    "cached/gifts/#{model.id}"
  end

  def extension_white_list
    %w(jpg jpeg gif png)
  end

  version :s300 do
    process resize_to_fit: [300, 300]
  end

  version :s200, :from_version => :s300 do
    process resize_to_fit: [200, 200]
  end

  version :s150, :from_version => :s200 do
    process resize_to_fit: [150, 150]
  end

  version :sq150 do 
    process resize_to_fill: [150, 150]    
  end  

  version :s75, :from_version => :s150 do
    process resize_to_fit: [75, 75]
  end

  version :sq75 do 
    process resize_to_fill: [75, 75]    
  end

end

What I need help with:

• Since my major issue is that this all fails silently, I cannot even begin to troubleshoot the function. Any suggestion on how I could trial-and-error troubleshoot this app until I can get some information on the error would be highly appreciated.
• If you can see anything in the code that would solve the problem would of course be really useful as well!

Answer 1

I solved this using carrierwave-aws gem. The solution is too complex and too specific for my particular application to be of interest for future readers. Frankly, I am not really sure why this solved this issue.