Note the last change log entry for MojoX::Session:

0.08    2009-01-25 00:00:00
        - tx is passed to session now
        - correct ip_match behavior
[download]

This is either suspicious or just a coincidence.

You might want to check that you haven't just upgraded to 0.08 and got a "working" ip_match, which has started turfing your dummy test IP addresses.

Ahhh... hmmmmm.... “By Jove, I think you‘ve got it ... ” Certainly the best-guess as to a culprit.

What puzzles me is... I just refreshed everything, and it still fails both in test and in Apache. Which, as far as I know, it did not do before. (As in, earlier this week.)

Maybe look for any calls of the form: MojoX::Session->new(..., ip_match => 1);.

MojoX::Session may have suddenly started honoring the cross check on these dummy IP's (and failing) where it wasn't before.

Ouch! Please stop the head banging RIGHT NOW ;-)

More seriously, behavior = code + inputs + environment. So if you are absolutely sure that

• no code changes and even your version control diff command agrees
• no 3rd party library code changes
• no changes to build scripts
• no anything recompiled a slightly different way
• no test suite changes
• the exact same test data worked yesterday
• all test "random" generators are seeded the same way

That pretty much leaves the option that your software is interacting with some part of the environment in ways you do not expect. Either (a) you have always been getting the undef but were traversing the code in a way it didn't matter or (b) some environmental factor is interacting with upstream code causing the undef IP address.

The obvious environmental things to look for are:

• database configuration and contents changes
• Apache server configuration changes
• Environment variables
• Your own profiles (or that of the user under which you are running the tests)
• Any bits of code that interact with the above

Failing that, go out and take a walk, pet the dog, play with the kids, or call a good friend and chat or do something having nothing to do with the problem. More than once, I've gotten myself entirely frustrated with a bug, only to have lunch with a friend, come back, and find the bugger in less than five minutes.

But you know all this, so you can probably go back to your head banging after reading this. Just choose a pillow next time. :-)

Wish I could help more, beth

go out and take a walk

Good advice. And before you go for that walk, why not at least log off your computer, or even cycle its power.

I'm confused. In your answer to snoopy you seem to suggest that you changed to a new version of Mojo. But still you declare your mantra "The code didn't change". Now what is it? Did you update any part of Mojo? Did you maybe update but didn't restart the server until a few days ago?

If yes, look at the changes in Mojo for your problem. Or ask a Mojo developer. It may be a bug in Mojo in which case staring at your code won't help you. (Also if you missed it Your Mother suggested a downgrade to see what happens on the chatterbox)

Yes, I did miss that recommendation.

Is it seriously possible (I doubt it...) that Mojo could really be “so seriously broken that Cookies don't work anymore?”

No, when I diff the two versions (of MojoX::Session), I don't see a substantial difference.

One mans broken is another mans feature. The new version might have changed something internally that your code expected to behave a certain way but was never written in stone, just to give one example of how it might not be a "seriously" big bug.

Sometimes when I had a really difficult-to-find bug in my code I later found out that a presumption I was absolutely sure about turned out to be false.

The most-peculiar thing is that... again, without any code changes that I can see... set-cookie requests are no longer being offered by the site. There are no proxies in the way. My browser is not refusing cookies. (An examination of the HTML response header in Firebug confirms that a set-cookie request is not present.)

The code is this, and I have verified that it is running:

sub _build_session {
    my $self = shift;
    
    my $store;
    my $schema = $self->_session_schema;  # LAZY...
    $schema->storage->dbh_do (        
        sub {
            my ($storage, $dbh) = @_;
            
            $store   = MojoX::Session::Store::DBI->new( 
                dbh         => $dbh,
                table        => 'blah',
                sid_column    => 'sid',
                expires_column    => 'expires',
                data_column    => 'data',
                );
        }  
    );
    croak "SPE::Context: BUG, failed to make session"
        unless defined $store;
        
        instance($self->tx, 'Mojo::Transaction');   # Data::Util...

    # So far so good... create the transport and the session-object.
    
    my $transport = 
          MojoX::Session::Transport::Cookie->new ( tx => $self->tx );
    my $session = 
          MojoX::Session->new(
            store            => $store,
            transport        => $transport,
            ip_match        => 0,
            );

    $session->load();
    if ( defined($session->sid()) ) {
        if ($session->is_expired()) {
            $session->flush();
            $session->create();
print STDERR "MyMojo::Context: session expired(1) and was re-created\n
+";
        } else {
print STDERR "MyMojo::Context: resuming session '".$session->sid()."'\
+n";    
        };
    } else {
print STDERR "MyMojo::Context: new session created\n";
        $session->create();
    };

    if ($session->is_expired()) {
print STDERR "MyMojo::Context: session expired(2) and was re-created\n
+";
        $session->flush;
        $session->create;
    } else {
print STDERR "MyMojo::Context: session extended\n";
        $session->extend_expires;
    };
    
    return $session;
}
[download]

The observed symptoms are these:

• This is all code that used to work perfectly. I have no reason to think that the root cause of the problem is actually here. (But... that is why I am humbly asking the Monks.)
• The site's HTML headers no longer offer to set a cookie. (There are no proxies in the way.)
• A session-record is created in the database, but since there is no cookie, there is no SID and therefore the session is never used.
• The sequence of STDERR debugging-messages in the above code-path is always:   new session created then session extended.
• The instance() calls are from Data::Util and are used to assert that the variable is, in fact, a (non-undef) instance of a variable of, or descended from, the specified class. Since the code does not die, the assertion must be true.

I am, needless to say, quite baffled.