This project is archived and is in readonly mode.

#2734 ✓resolved
Sam Ruby

git HEAD regression: sessions lose changes

Reported by Sam Ruby | May 28th, 2009 @ 06:36 PM | in 3.0.2


get /store/add_to_cart/2 =>
1 × Pragmatic Project Automation

get /store/add_to_cart/2 =>
2 × Pragmatic Project Automation

get /store/add_to_cart/3 =>
1 × Pragmatic Project Automation 1 × Pragmatic Version Control

[note: one of the copies of PPA was lost]

This is broken by the following commit:

Comments and changes to this ticket

  • Sam Ruby

    Sam Ruby May 28th, 2009 @ 09:12 PM

    Attached is a patch to Rails that get the tests to pass again. Warning: it does so by effectively reverting this change.

    The test cases isn't minimal, but is relatively small. Setup should take less than a minute:

    git clone git://
    cd awdwr
    ruby makedepot.rb 6.1-7.4 save

    Once that is complete, the scenario itself can be repeated at will with the following:

    ruby makedepot.rb restore 8.1-8.5

    In both cases, replace with the path to your checkout of Rails.

  • Sam Ruby

    Sam Ruby May 29th, 2009 @ 06:27 AM

    • Tag changed from 3.0, session to 3.0, patch, session
  • josh

    josh May 29th, 2009 @ 04:32 PM

    • Milestone cleared.
    • State changed from “new” to “open”

    I can't exactly tell how the failing example is setup. Can you setup a minimal case? Even better a unit test. It could be difficult if it is related to a reloading issue.

  • Sam Ruby

    Sam Ruby May 29th, 2009 @ 04:46 PM

    I'm traveling at the moment, so it will be a few days before I try to create a more minimal test case; but it does look like lighthouse mangled my instructions.

    A more legible set of instructions can be found at the following places:

    Applied to this ticket, the easiest way to reproduce this is to run sections 6.1-7.4 using a checked out version of Rails and save the results; and then continue from the restore point with sections 8.1-8.5 to see the error.

    It doesn't appear to be a reloading issue, but clearly is a regression. My suggestion is that the change be backed out (or disabled) until it can be debugged.

  • Sam Ruby

    Sam Ruby May 30th, 2009 @ 03:46 AM

    I've reviewed the code in question, and here is what I found: the commit in question optimizes out writing out sessions unless a direct assignment is made to the session object.

    In my case, the session contains a Cart object. The first request will cause the Cart to be added to the session. Subsequent requests won't directly assign to the session, but will update the cart object.

  • josh

    josh May 30th, 2009 @ 03:33 PM

    • State changed from “open” to “resolved”

    Thats a clear reason, reverting.

  • Jeremy Kemper

    Jeremy Kemper October 15th, 2010 @ 11:01 PM

    • Milestone set to 3.0.2
    • Importance changed from “” to “Medium”

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href=""></a>

People watching this ticket