Что вызывает «ArgumentError (ошибка формата дампа)»?

Question

При устранении неполадок в Spree, когда список продуктов не разбивался на страницы и в нем были перечислены только первые 10 продуктов или около того, я попытался воспроизвести ошибку в локальной среде разработки, и при загрузке первой страницы я получил ошибку:1001 *

ArgumentError (dump format error)

Как всегда, я сначала проверил свой другой мозг.Лучший результат поиска был: https://github.com/rails/rails/issues/2509

Хотя пользователь, который запустил этот поток, и несколько других авторов пытались обновить Rails 3.0.9 до Rails 3.1, я не думал, что это применимов моем случае.Приложение Spree 0.60.2, которое я запускаю, находится на Rails 3.0.9.

Однако, как оказалось, простая очистка моих локальных файлов cookie решила проблему.Почему?

Answer 1

Я собираюсь предположить, что, поскольку в моей среде разработки запущено несколько приложений, в том числе версия того же приложения на Rails 3.1 / Spree 0.70, и я посещаю все из них через localhost, возник конфликтчто-то вроде файлов cookie, где версия 3.1 устанавливает файлы cookie, которые версия 3.0.9 не может съесть.Вероятно, это связано с тем, что @Fjan упомянул в своем посте здесь (https://github.com/rails/rails/issues/2509):

Я проследил эту ошибку, и это происходит потому, что класс FlashHash в сеансе был изменен, чтобы больше не наследовать отКласс хеширования в рельсах 3.1.

Я провел эксперимент. При условии, что я выполнил , а не вход в систему для любой версии приложения, я мог бы запустить одну из них, закрыть ее и запуститьдругой и не столкнуться с этой проблемой либо. Однако, когда я вошел в версию 3.0.9, а затем выключил этот сервер и запустил версию 3.1, я снова получил ту же ошибку. Вот частичный след:

activesupport (3.1.1) lib / active_support / message_verifier.rb: 34: в 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: в []' actionpack (3.1.1) lib/action_dispatch/middleware/session/cookie_store.rb:53:inблок в unpacked_cookie_data 'actionpack (3.1.1) lib / action_dispatch / middleware / session / abstract_store.rb: 55: в 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: в extract_session_id' actionpack (3.1.1) lib/action_dispatch/middleware/session/abstract_store.rb:51:in блок в экстрактеt_session_id 'actionpack (3.1.1) lib / action_dispatch / middleware / session / abstract_store.rb: 55: в 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: в 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: в 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: в has_key?' actionpack (3.1.1) lib/action_dispatch/middleware/flash.rb:260:in обеспечить в вызове' actionpack (3.1.1) lib / action_dispatch / middleware / flash.rb: 261: в call' rack (1.3.6) lib/rack/session/abstract/id.rb:195:in контексте 'rack (1.3.6) lib / rack / session / abstract / id.rb: 190: в `call'

Обратноетакже верно. Когда я вошел в версию 3.1, а затем выключил этот сервер и запустил версию 3.0.9, я получил ту же ошибку.Вот частичная трассировка:

activesupport (3.0.9) lib / active_support / message_verifier.rb: 34: в 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: в []' actionpack (3.0.9) lib/action_dispatch/middleware/session/cookie_store.rb:68:in блоке в unpacked_cookie_data 'actionpack (3.0.9) lib / action_dispatch / middleware / session / abstract_store.rb: 223: в 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: в []' 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: в exists?' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:96:in существует?'actionpack (3.0.9) lib / action_dispatch / middleware / session / abstract_store.rb: 113: в 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: в call' actionpack (3.0.9) lib/action_dispatch/middleware/session/abstract_store.rb:149:in вызов'

Что примечательно для меня, так это то, что вам не нужно буквально находиться в процессе обновления.Чтобы воспроизвести эту проблему, вам нужно всего лишь запустить два приложения, охватывающих эти две версии Rails, которые устанавливают файлы cookie с одинаковыми именами ... предположительно, либо последовательно (как в моем эксперименте), либо одновременно (что я не пробовал).

Надеюсь, кто-то еще предоставит более информированный ответ, чем этот, чтобы добавить детали, которых нет в этом свободном объяснении.В то же время, если вы столкнулись с этой проблемой в процессе разработки и вас не волнует внутреннее функционирование, просто удалите файлы cookie (как предложено @tscolari в указанной выше ветке: https://github.com/rails/rails/issues/2509) и двигайтесь дальше.Ура

Answer 2

Я столкнулся с той же проблемой.Очистка файлов cookie браузера решила проблему.режим разработки.

Answer 3

Если вы находитесь на производстве и не можете попросить своих пользователей удалить куки :) - единственный способ - изменить ключ session_store в config / initializers / session_store.rb

Решение не из приятных, пользователь будетпридется заново войти.

Answer 4

Очистка ваших файлов cookie решит эту проблему, попробуйте открыть свое приложение с помощью другого браузера или инкогнито на chrome, оно будет работать нормально.

Answer 5

Я столкнулся с той же проблемой на производстве сразу после перехода на рельсы 3.2.

Изменение ключа session_store в соответствии с предложением @povkys было бы немного излишним в моем случае, поскольку только некоторые пользователи (менее 1%) испытывали проблемы со своими сеансами.

В итоге я запустил скрипт для анализа всех сессий в базе данных и удаления недопустимых. Вот код, на случай, если он кому-нибудь поможет:

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