¿Qué causa el "ArgumentError (error de formato de volcado)"?

Question

Al resolver un error en Spree donde la lista de productos no estaba paginating y solo estaba enumerando los primeros 10 productos, intenté reproducir el error en mi entorno de desarrollo local y en la primera página cargué el error:

ArgumentError (dump format error) 

Como siempre, primero revisé mi otro cerebro. El resultado de búsqueda superior fue: https://github.com/rails/rails/issues/2509

Aunque el usuario que inició ese hilo y varios de los otros carteles intentaban una actualización de Rails 3.0.9 a Rails 3.1, no pensé que se aplicaría a mi caso. La aplicación Spree 0.60.2 que estoy ejecutando está en Rails 3.0.9.

Sin embargo, como resultado, simplemente borrar mis cookies de localhost resolvió el problema. ¿Por qué?

Answer 1

Voy a especular que debido a que estoy ejecutando varias aplicaciones en mi entorno de desarrollo, incluyendo una versión de Rails 3.1/Spree 0.70 de la misma aplicación, y las visito a través de localhost, que hubo un conflicto de algún tipo en las cookies, donde la versión 3.1 establece algunas cookies que la versión 3.0.9 no puede comer. Probablemente tiene que ver con lo que @Fjan menciona en su post aquí (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.

Me corrió un experimento. Si hice no inicio de sesión en cualquier versión de la aplicación, podría iniciar una y cerrarla y comenzar la otra y no tener este problema tampoco. Sin embargo, cuando inicié sesión en la versión 3.0.9 y luego cerré ese servidor y lancé la versión 3.1, recibí el mismo error una vez más. Aquí está una traza parcial:

activesupport (3.1.1) lib/active_support/message_verifier.rb:34:in load' activesupport (3.1.1) lib/active_support/message_verifier.rb:34:in verify' 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:in block 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:in block 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:in session_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:in load_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:in ensure 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:in context' rack (1.3.6) lib/rack/session/abstract/id.rb:190:in `call'

Lo contrario también es cierto. Cuando inicié sesión en la versión 3.1 y luego apago ese servidor y lanzo la versión 3.0.9, recibí el mismo error. Aquí está una traza parcial:

activesupport (3.0.9) lib/active_support/message_verifier.rb:34:in load' activesupport (3.0.9) lib/active_support/message_verifier.rb:34:in verify' 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:in block 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:in call'

Lo que es notable para mí es que no es necesario ser, literalmente, en el proceso de actualización. Para reproducir este problema, solo necesita ejecutar dos aplicaciones que abarquen estas dos versiones de Rails que están configurando cookies con los mismos nombres ... presumiblemente en secuencia (como en mi experimento) o concurrentemente (que no he probado).

Afortunadamente, alguien más aquí proporcionará una respuesta mejor informada que esta para agregar los detalles que carece esta explicación. Mientras tanto, si se encuentra con este problema en desarrollo y no le importa el funcionamiento interno, simplemente borre sus cookies (como lo sugiere @tscolari en el hilo al que se hace referencia anteriormente: https://github.com/rails/rails/issues/2509) y siga adelante. Aclamaciones.

Answer 2

Limpiar las cookies resolvería este problema, intente abrir su aplicación con un navegador diferente o de incógnito en Chrome, funcionará bien.

Answer 3

Si usted está en producción y no se puede pedir a los usuarios borrar las cookies :) - la única manera es cambiar session_store clave en config/inicializadores/session_store.rb

La solución no es agradable, el usuario tendrá para volver a iniciar sesión

Answer 4

Tuve el mismo problema. La eliminación de las cookies del navegador resolvió el problema. modo de desarrollo.

Answer 5

Me encontré con el mismo problema en la producción justo después de pasar a los carriles 3.2.

Cambiar la clave session_store según lo sugerido por @povkys hubiera sido un poco exagerado en mi caso ya que solo algunos usuarios (menos del 1%) tuvieron problemas con sus sesiones.

Terminé ejecutando un script para analizar todas las sesiones de la base de datos y eliminar las que no son válidas. Aquí está el código, en caso de que ayude a alguien:

current_id = 0 
failed_count = 0 
while (sessions = ActiveRecord::Base.connection.select_all("Select id, data from sessions where id > #{current_id} limit 1000")).count > 0 do 
    failed_ids = [] 
    sessions.each do |s| 
    begin 
     ActiveRecord::SessionStore::Session.unmarshal(s['data']) 
    rescue 
     failed_count += 1 
     failed_ids.push s['id'] 
    end 
    end 

    ActiveRecord::Base.connection.execute("DELETE FROM sessions WHERE id in (#{failed_ids.join ','})") unless failed_ids.empty? 
    current_id = sessions.last['id'] 
end 
failed_count