Problems with multiple process_in_background calls about delayed_paperclip HOT 4 OPEN

@dan Looking at delayed_paperclip code it looks like there is some memoization going on so perhaps you should try this:

has_attached_file :photo, {
  styles: {
    thumb:  ['100x100#', :jpg],
    medium: ['300x300#', :jpg],
  }
}.merge(PAPERCLIP_STORAGE_OPTIONS)

has_attached_file :picture, {
  styles: {
    thumb:  ['100x100#', :jpg],
    medium: ['300x300#', :jpg],
  }
}.merge(PAPERCLIP_STORAGE_OPTIONS)

process_in_background :photo
process_in_background :picture

from delayed_paperclip.

This looks like a legit bug in the way delayed_paperclip stores its data

process_in_background uses paperclip_definitions to store options for the delayed processing. paperclip_definitions caches the object it gets back from calling either attachment_definitions or Paperclip::Tasks::Attachments.definitions_for(self). Looking at paperclip master, definitions_for no longer exists, but attachment_definitions still does which hits Paperclip::AttachmentRegistry.definitions_for(self) which always returns a new hash with the current state of defined attachments. Due to the caching, this object won't be updated when new attachments are defined, so the second call cannot find any attachments defined after the first.

Looks like @jdguzman posted a workaround. As for delayed_paperclip, I think it should try and handle its own data, separate from paperclip's internal data.

from delayed_paperclip.

@ryansouza I agree that this looks like a bug. The quick and dirty solution would be to remove the memoization and take the, probably small, performance hit.

I may take a stab at a better solution later when I'm not under piles of work.

from delayed_paperclip.

Thanks for looking at this in depth. Pull requests would be very much appreciated.

from delayed_paperclip.