I don't think having a not-booted kernel is possible. I saw this failure when working on #45479, and the issue was a badly mock. This is what should be fixed on newly failing tests. See patch on #45479.

I'd prefer not blindly ignoring an exception.

It's possible when you use several clients, the pseudo-code is something like this:

$client = self::createClient();
$client->request();
self::ensureKernelShutdown();
$otherClient = self::createClient();
$otherClient->request();

// Now fails
$client->request();

Had the same in a personal project.

Simple reproducer:

$client = self::createClient();
$client->request('GET', '/user');
$client->request('GET', '/user'); <== reboot the container

static::getContainer(); <= throws Could not find service "test.service_container"....

Can you figure out a realistic test case ?

Does calling disableReboot() work around the issue btw?

@jderusse I don't think the proposed fix works for your case, isn't it? It looks like you are impacted by the reset itself, not just getting the container.

Can you figure out a realistic test case ?

Do you mean to write a non-regression test in this PR with my scenario?

Does calling disableReboot() work around the issue btw?

Yes but I hope I don't have to call it everywhere after a patch release 😬 Another workaround is to boot the kernel manually btw but then it shutdowns it and then reboots it again 😓

$client->getKernel()->boot()

Can you figure out a realistic test case ?

Here is more context about the failing test:

$client = self::createClient();

$crawler = $this->request('GET', '/user');

$client->submit($crawler->selectButton('Save')->form([
  'profile[email]' => 'foo@bar.com',
]));

$user = static::getContainer()->get(UserRepository::class)->findOneBy(['email' => 'foo@bar.com']);

static::assertNotNull($user);

Does calling disableReboot() work around the issue btw?

Yes, but this is not what I want.

Other workarounds:

• replace static::getContainer() by $client->getContainer()
• adding $container = static::getContainer(); before the second request and then replace static::getContainer() by $container

I'm seeing the same thing, another workaround:

$client = self::createClient();
$client->request('GET', '/user');
$client->request('GET', '/user'); <== reboot the container

static::ensureKernelShutdown(); // fix

static::getContainer();

All of this is due to the merge of https://github.com/symfony/framework-bundle/blame/5.4/KernelBrowser.php#L175

Container is now reset between requests, whereas it wasn't before. Not sure why we need to reset the Container between each and every request.

This PR is only linked to the reset problem. It won't fix it.

This PR only fixes getting the container from a non-booted kernel.

@fancyweb, you're right, there appears to be two separate issues here.

Yes but OFC if the fix for the reset issue ends up removing getting the container here, this issue will also be fixed 😃

This issue also occurs when following a redirect and trying to fetch a service to do some assertions

public function testRedirect(): void
{
    $client = self::createClient();
    $client->request('GET', '/redirect');

    // works
    $service = self::getContainer()->get(Service::class);
    $service->method();

    // Follow redirect
    $crawler = $client->followRedirect();

    // does not work
    $service = self::getContainer()->get(Service::class);
    $service->method();
    $this->assertStringContainsString('OK', $crawler->text());
}

What's odd to me is that TestContainer overrides the reset() method so that it has no effect (see: https://github.com/symfony/symfony/blob/6.1/src/Symfony/Bundle/FrameworkBundle/Test/TestContainer.php#L123). So it means the instance of Container that KernelBrowser handles is not a test container?

Replaced by #45595, thanks for the test case :)