@Drak: can you help-me with this issue?

Can you show me the tests?

https://gist.github.com/2279935

As you can see, it's a simple test, and phpunit configuration file it's the sf default. Note that i'm using the most recent version on the master branch.

Thanks

Note to others, we are discussing and investigating together on this.

What I do't quite understand is why the tests pass in FrameworkBundle/Tests/Functional as these also use sessions. I haven't been able to see what the difference is between the tests, except for the invokation of the client. Does anyone have some idea?

any news ?

@Drak, here simple test which is not passed.

@yethee in your test you modify the session but your first request is made without a cookie which holds the session id (so the session cannot be restored). I'd say it should work if you save the session and send a proper cookie (but it doesn't).

Exception is thrown in MockArraySessionStorage::setId(). I'm not sure if it's a bug. For some (probably good) reason it's forbidden to re-set the session id.

If you made a request before altering the session it'd properly set the cookie and your test would pass.

public function testPredefinedSession()
{
    $client = $this->createClient(array('test_case' => 'Session', 'root_config' => 'config.yml'));
    $client->request('GET', '/session');

    $session = static::$kernel->getContainer()->get('session');
    $session->set('name', 'foo');
    $session->save();

    $crawler = $client->request('GET', '/session');
    $this->assertContains('Welcome back foo, nice to meet you.', $crawler->text());
}

Notice you also need to save the session before making a request.

Anyone else has thoughts on this?

ping @Drak

@fabpot - I'm temporarily stumped on this, have you some idea? The tests work in FrameworkBundle/Tests/Functional, yet other people's tests don't work. I don't get it.

From what I can see, the listener order is correct, ie the test listeners fire before the session is started by the other listener, at least, in code it looks ok.

@Drak look at the @yethee's test. He accesses the session before first request is made (and therefore it's already started).

@jakzal - in @yethee's case yes, but the tests shown by @diegoholiveira don't appear to be down to user implementation. The problem is, removing the exceptions is OK, but they were added explicitly to trap this kind of thing, so clearly something deeper is going on.

Without the exception the problem is the same. The session doesn't work with behat (i can't test a simple login page)

@benji07 are you using FrameworkBundle or not, because FrameworkBundle has a listener which saves sessions (when in test mode).

I use the standard edition on master branch, i add mink, and try to test the login page

it's work with symfony session, not with zombie.js

EDIT: it's work with sahi too (maybe there are a but with zombie.js)

@Drak would be helpful if someone linked to/pasted @diegoholiveira's tests.

@jakzal sorry dude, i don't understand what you mean. Did you like to take a look into my tests?

@diegoholiveira sorry, i didn't notice your link....

@jakzal no problems :)

If you need something, just ping me.

Hi,

I'm jumping in since I'm now facing this issue as well. Here a test case failing:

<?php

namespace Acme\UpartyBundle\Tests\Controller;

use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;

class UserControllerTest extends WebTestCase
{
    public function testCreateUser()
    {
        $client = $this->createClient();
        $crawler = $client->request('GET', '/en/user/create');
    }
}

When I started to work today, tests were ok. Then, I added JMSDebuggingBundle and updated Symfony 2.1 dependencies then tests stopped working. Last time I updated, its when Form options were fixed, so it like 8 days ago from now.

The failing machine is on Mac OS X, I have another box at home, which is on Windows and with the project not updated yet. I will make some test tonight or tomorrow morning to see what caused the problem to arise now and not before. Maybe it could help with the debugging of the problem.

Regards,
Matt

Here a follow-up of my previous post.

Today, I tried to revert to a previous working state and tests were passing as expected with a preivous version of my project. Since the last thing I had done before it failed was adding JMSDebuggingBundle and updating Symfony, I tought I should try to remove the bundle to see if it was working. It did.

So, I went back to the HEAD of my branch to have my project fully up-to-date and tried to disable the bundle. This also made the tests passed.

So, my conclusion is that, in my case, the bundle was interacting badly with the session somehow which is triggering the errors in my tests. The current workaround I did is to disable the JMSDebuggingBundle when the environment is test. Here the code:

if (in_array($this->getEnvironment(), array('dev', 'test'))) {
    $bundles[] = new Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();

    if ($this->getEnvironment() === 'dev') {
        $bundles[] = new JMS\DebuggingBundle\JMSDebuggingBundle($this);
    }
}

I thought it could be the custom container class provided with the bundle that was breaking something, but it wasn't the case since commenting the code changing the container base class did not make the tests pass. Once again, I'm changing the container base class only in dev environment to workaround this issue.

Anyone in this thread having the error is using JMSDebuggingBundle? It could also a bad interaction with any other bundle. But one certitude, in my case, this was the offending bundle.

Hope it helps to resolve this issue.

Regards,
Matt

I'm not using JMSDebuggingBundle. In fact, i'm just using the default bundles that come into symfony-standard.

:)

Hello again,

Since @diegoholiveira is using only default bundles, it is clearly not only JMSDebuggingBundle that triggers this error. So, I went ahead and searched a bit on what is going on. Here my findings.

I'm my project, I'm also using FOSFacebookBundle to authenticate users. Before adding JMSDebuggingBundle, every tests were passing. When I added it, it started to break. FOSFacebookBundle is working with the session at some point to retrieve some information from it. The main class that deals with session is FacebookSessionPersistence. If I comment everything related to the object session in it, my tests passed (well, no but they don't trigger the exception mentionned in this issue).

1. My project with FOSFacebookBundle only => Ok
2. My project with FOSFacebookBundle & JMSDebuggingBundle => Exception
3. My project with FOSFacebookBundle & JMSDebuggingBundle but with session stuff in FacebookSessionPersistence commented out => Ok

A weird interaction is going on since activating JMSDebuggingBundle triggers the error on my project but it is not bundle's direct fault because it can work if some code in FOSFacebookBundle is commented out.

So, I decided to find a way for others to reproduce this error. What you can do is to checkout symfony-standard, add FOSFacebookBundle and JMSDebuggingBundle, configure them (FOSFacebookBundle can by configured with false app_id and app_secret), configure the security configuration to use FOSFacebookBundle. Magic, tests will fail with the LogicException about session already started.

To make it easy to reproduce, I cloned current symfony-standard and configured it with the stuff required to reproduce this problem. I pushed it on my own repo on Github. You can find this customized symfony-standard in my test_session_listener_problem branch.

If you clone my repo, checkout branch test_session_listener_problem, run php composer.phar install then go in folder app/ and run phpunit, you should see the exception.

If you then comment $bundles[] = new JMS\DebuggingBundle\JMSDebuggingBundle($this); in AppKernel.php, test will be ok and you will not see the exception.

I cannot conclude if this a Symfony bug or not. Only thing I can say, this is a bizarre issue and seems to be related to integration of code. Since @diegoholiveira use default bundles from symfony-standard, I guess his code must contain something that triggers this error.

Again, hope this helps to sort out this weird issue :)

Regards,
Matt

Hi Matt,

Sorry dude, but I give you WRONG information about my project. I'm using FOSFacebookBundle too (I just remember that I'm using when I see you last response, it's easy to forgot about it because it's something that we not deal directly every day...)

@diegoholiveira No problem at all :), it may now be easier to debug the issue. This seems in some way related to FOSFacebookBundle. What I found odd is that without JMSDebuggingBundle, I don't have this issue at all. But with it enabled, the error is triggered. So weird.

It could potentially be related to this FOSFacebookBundle issue.

After reading more thoroughly issue #79 of FOSFacebookBundle, I think the issue we are seeing is directly caused by facebook bundle. I still have no clue why JMSDebuggingBundle triggers the problem on my project, but I'm 90% sure FOSFacebookBundle is the culprit of this issue.

Maybe @Drak could confirm my hypothesis.

also seeing this issue when updating. i am not using FOSFacebookBundle, but a fairly hacked up version of Sensio's CasBundle

Some more information about my use case. My provider class has a dependency on a service that in turn requires the container. I managed to fix the issue by instead injecting the container and then only fetching the session lazily .. but not instead the constructor.

@lsmith77 @maoueh @Drak @diegoholiveira I am experiencing the same problem right now.
I don't use ANY of the mentioned bundles, but for testing I use the LiipFunctionalTestBundle. Under this situation, I try to emulate a login of a user, which triggers the start of the Session and then it fails internally.

@Drak @stof By commenting the lines:

} else {
    $session->setId('');
}

The issue is now fixed in my environment.

I had the same problem. In my case the problem was I had an event listener which had this code:

$this->session->start();

As it is described in this isuue FriendsOfSymfony/FOSFacebookBundle#79 the problem is to start the session too early.