Carrierwave - destroy object only after it has been deleted from my storage

Question

Carrierwave only deletes the 'mounted' file after the object in the database has been removed:

after_commit :remove_avatar! :on => :destroy

https://github.com/carrierwaveuploader/carrierwave

I am implementing a Backgrounddestroyable Center and for that I have a worker who deletes the files.

The field deleted_at records when the object was marked for complete removal and to ensure that the objects are only actually removed by the worker I needed to reset the destroy at the conference.

If one of the Workers receives a timeout I lose the reference of my orphaned files in S3, since my objects in the database have been deleted.

What should I do to make sure I don’t end up with orphans in S3? Call remove_avatar! right before the object.destroy and then make a skip_callback?

It’s safe to do that?

Answer 1

What I did was call remove_avatar! before calling super() and do the removal indeed, without changing anything in the callbacks.

For registration, follow the code of the Concern:

# BackgroundDestroyable classes MUST have deleted_at:datetime column
module BackgroundDestroyable
  extend ActiveSupport::Concern

  included do
    default_scope { where(deleted_at: nil) }
    scope :deleted, -> { unscoped.where.not(deleted_at: nil) }
  end

  def destroy(mode = :background)
    if mode == :background
      unless self.deleted_at.present?
        update_attribute :deleted_at, Time.now
        Resque.enqueue(BackgroundDestroyer, self.id, self.class.to_s)
      end
    elsif mode == :now
      self.class.uploaders.each do |uploader, uploader_class|
        self.send("remove_#{uploader}!")
      end
      super()
    end
  end

  def destroy_now!
    self.destroy(:now)
  end
end

Answer 2

For me, it makes more sense to call remove_avatar! before calling the object.destroy. Thus, you can always ensure that you will not have orphaned objects in S3, checking whether the object has actually been removed.

I’d rather not touch the callbacks, unless I know exactly what I’m doing. Also, I always prefer to leave the explicit behavior in the code and callbacks are not very explicit. And, from experience, you’ll be thanking yourself in a few months when you need to look at this script and do some maintenance on it.