What causes the "ArgumentError (dump format error)"?

Question

While troubleshooting a misbehavior in Spree where the product list was not paginating and was only listing the first 10 products or so, I attempted to reproduce the error in my local development environment and on the first page load I received the error:

ArgumentError (dump format error)

As always, I checked my other brain first. The top search result was: https://github.com/rails/rails/issues/2509

Although the the user who started that thread and several of the other posters were attempting an upgrade from Rails 3.0.9 to Rails 3.1, I didn't think it would apply to my case. The Spree 0.60.2 app I'm running is at Rails 3.0.9.

However, as it turns out, simply clearing my localhost cookies solved the problem. Why?

Answer 1

I'm going to speculate that because I'm running multiple applications in my development environment, including a Rails 3.1/Spree 0.70 version of the same app, and I visit all of them via localhost, that there was a conflict of some sort in the cookies, where the 3.1 version set some cookie that the 3.0.9 version couldn't eat. It probably has to do with what @Fjan mentioned in his post here (https://github.com/rails/rails/issues/2509):

I traced this error and it happens because the FlashHash class in the session has been changed to no longer inherit from the Hash class in rails 3.1.

I ran an experiment. Provided I did not login on either version of the app, I could start one up and shut it down and start the other and not run into this problem on either. However, when I logged into the 3.0.9 version and then shut down that server and launched the 3.1 version, I received the same error once again. Here is a partial trace:

activesupport (3.1.1) lib/active_support/message_verifier.rb:34:in load' activesupport (3.1.1) lib/active_support/message_verifier.rb:34:inverify' actionpack (3.1.1) lib/action_dispatch/middleware/cookies.rb:280:in []' actionpack (3.1.1) lib/action_dispatch/middleware/session/cookie_store.rb:53:inblock in unpacked_cookie_data' actionpack (3.1.1) lib/action_dispatch/middleware/session/abstract_store.rb:55:in stale_session_check!' actionpack (3.1.1) lib/action_dispatch/middleware/session/cookie_store.rb:51:in unpacked_cookie_data' rack (1.3.6) lib/rack/session/cookie.rb:96:in extract_session_id' actionpack (3.1.1) lib/action_dispatch/middleware/session/abstract_store.rb:51:inblock in extract_session_id' actionpack (3.1.1) lib/action_dispatch/middleware/session/abstract_store.rb:55:in stale_session_check!' actionpack (3.1.1) lib/action_dispatch/middleware/session/abstract_store.rb:51:in extract_session_id' rack (1.3.6) lib/rack/session/abstract/id.rb:43:in load_session_id!' rack (1.3.6) lib/rack/session/abstract/id.rb:32:in[]' rack (1.3.6) lib/rack/session/abstract/id.rb:252:in current_session_id' rack (1.3.6) lib/rack/session/abstract/id.rb:258:insession_exists?' rack (1.3.6) lib/rack/session/abstract/id.rb:104:in exists?' rack (1.3.6) lib/rack/session/abstract/id.rb:114:inload_for_read!' rack (1.3.6) lib/rack/session/abstract/id.rb:64:in has_key?' actionpack (3.1.1) lib/action_dispatch/middleware/flash.rb:260:inensure in call' actionpack (3.1.1) lib/action_dispatch/middleware/flash.rb:261:in call' rack (1.3.6) lib/rack/session/abstract/id.rb:195:incontext' rack (1.3.6) lib/rack/session/abstract/id.rb:190:in `call'

The reverse was also true. When I logged into the 3.1 version and then shut down that server and launched the 3.0.9 version, I received the same error. Here is a partial trace:

activesupport (3.0.9) lib/active_support/message_verifier.rb:34:in load' activesupport (3.0.9) lib/active_support/message_verifier.rb:34:inverify' actionpack (3.0.9) lib/action_dispatch/middleware/cookies.rb:253:in []' actionpack (3.0.9) lib/action_dispatch/middleware/session/cookie_store.rb:68:inblock in unpacked_cookie_data' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:223:in stale_session_check!' actionpack (3.0.9) lib/action_dispatch/middleware/session/cookie_store.rb:66:in unpacked_cookie_data' actionpack (3.0.9) lib/action_dispatch/middleware/session/cookie_store.rb:57:in extract_session_id' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:39:in load_session_id!' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:27:in []' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:210:in current_session_id' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:239:in exists?' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:96:in exists?' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:113:in load_for_read!' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:53:in[]' actionpack (3.0.9) lib/action_dispatch/middleware/flash.rb:178:in call' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:149:incall'

What's notable to me is that you needn't literally be in the process of upgrading. To reproduce this issue, you need only be running two apps spanning these two versions of Rails that are setting cookies with the same names...presumably either in sequence (as in my experiment) or concurrently (which I haven't tried).

Hopefully, someone else here will provide a better-informed answer than this to add the details this loose explanation lacks. In the meantime, if you're running into this issue in development and you don't care about the inner workings, just clear your cookies (as suggested by @tscolari in the thread referenced above: https://github.com/rails/rails/issues/2509) and move along. Cheers.