Error "can't dump anonymous class" with friendly_id and caching #314

malagoli opened this Issue Jul 14, 2012 · 11 comments


None yet
4 participants

I'm currently using rails 3.2.3 with friendly_id 4.0.7. In my configuration I can't cache a model when I enable friendly_id for it.

My model is like:
class ModelName < ActiveRecord::Base
extend FriendlyId
friendly_id :name, :use => [:slugged]

def self.all
Rails.cache.fetch('BRAND_ALL', :expires_in => 24.hours) do

whenever I try to access the all function I get the following error:
can't dump anonymous class #Class:0x00000004eb9278

activesupport (3.2.3) lib/active_support/cache.rb:561:in dump' activesupport (3.2.3) lib/active_support/cache.rb:561:ininitialize'
activesupport (3.2.3) lib/active_support/cache.rb:363:in new' activesupport (3.2.3) lib/active_support/cache.rb:363:inblock in write'
activesupport (3.2.3) lib/active_support/cache.rb:520:in instrument' activesupport (3.2.3) lib/active_support/cache.rb:362:inwrite'
activesupport (3.2.3) lib/active_support/cache.rb:299:in fetch' actionpack (3.2.3) lib/action_controller/metal/implicit_render.rb:4:insend_action'

It seams to be a problem related to marshalling, have you ever encountered something similar?




parndt commented Jul 14, 2012

Still present if you use Rails 3.2.6?


norman commented Jul 15, 2012

Can you please include the full stack trace? I can imagine a few places this might come from and possibly be fixed, and the full stack trace that includes lines from FriendlyId would be helpful.

Hi, solved was my fault (I was caching a scope result). It was quite strange that the error ws present only with friendly_id enabled

@malagoli malagoli closed this Jul 16, 2012


norman commented Jul 16, 2012

Cool, thanks for the followup. I think it still could be partly friend_id's
fault, if you get a chance send over the whole backtrace and I'll look into

jess commented Jul 20, 2012

I have a similar issue.

I'm getting the error:

TypeError in Store::CartController#show
can't dump anonymous class #Class:0x007fb634cca9d8

I'm not using caching...but sessions.

I'm using sessions for a cart. Something like this:

# app/models/cart
class Cart
  attr_reader :items

  def initialize
    @items = []

  def add(product)
    @items << product

# controller
product = Product.find(params[:id]) #this would be the slug
@cart = session[:cart] ||=

Now in my view:

@cart.items.each do |item| #works fine #causes the error

Here's the link to the trace. If I comment out friendly id in the
Gemfile and remove the friendly_id references from my models, it works

** Strange bit: I'm using pry to debug. I can insert binding.pry
anywhere before the view reference to the association
( and have no problem accessing the objects and their


norman commented Jul 20, 2012

Thanks for the detailed info, @jess, that's super helpful. I'm on paternity leave right now and don't have much time to look at this for the next week or two, but if I get a chance to look I will. In the mean time I'll reopen the issue in case anyone else has a chance to work on it.

To that end, anybody looking to track this down might want to have a look here which I think is the likely source of the marshall error (also brought up in issue #306). I'm not sure if simply naming the class is sufficient to avoid the marshall error, but it may be worth looking into.

@norman norman reopened this Jul 20, 2012

jess commented Jul 22, 2012

Hi @norman, congrats on the baby, your first?

I extracted out the code that was giving me problems into a really simple sample app. Sorry I don't know enough to help fix the issue, but maybe this will help narrow the focus.

Here's a screencast showing the issue:

Here's the sample app:

There are 2 branches, master works, friendly_id branch breaks.

Hopefully I'm not making a dumb mistake somewhere, because it seems pretty basic setup??

Let me know if I can help more.


parndt commented Jul 22, 2012

Good example application - thanks for including the screencast. It is indeed the fault of the code that @norman pointed out earlier and I'm currently looking to see if we can use something else.

parndt added a commit that referenced this issue Jul 22, 2012

Added tests to prove Marshal behaviour.
For #314
The relationship test fails when Marshaling.

parndt commented Jul 22, 2012

I've added a test case to reproduce this issue which fails as expected and I'm out of time right now to continue looking. Hopefully this helps the next person (or future @parndt).

@norman norman closed this in 451b88d Aug 1, 2012


norman commented Aug 1, 2012

Just committed the fix for this and will push out a new version today. Thanks again @jess for the help!

jess commented Aug 1, 2012

Nice, good job! I tried to fix it, but didn't know how to name the class (I wasn't aware of const_set).

Funny, I ran into the same (or at least similar) issue with carrier wave (jnicklas/carrierwave#793). Any advice for those guys? I'd guess they're doing the same thing...creating an anonymous class for versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment