Unfortunately this does not fix #19840 for me

@dmaicher the code you posted is broken: it misses the ContainerInterface::NULL_ON_INVALID_REFERENCE argument.

why exactly? I mean as long as I'm in the request scope it should be safe to retrieve the request service, right? I mean it worked with symfony 2.8.9 😊

So as far as I can see the problem is that here https://github.com/symfony/symfony/blob/2.8/src/Symfony/Component/HttpKernel/DependencyInjection/ContainerAwareHttpKernel.php#L82 the request is set to null which then triggers synchronizeRequestService which in my case then tries to retrieve the service again with get('request').

I checked a bit more to understand how null could end up as a service value in the container. The answer is on request-scope change: when leaving the main scope, ->set('request', null) is called, and this null value is finally unset only after synchronizeRequestService has been called.
See https://github.com/nicolas-grekas/symfony/blob/0db8822b104790cf1071f13e4ce37a717d19756e/src/Symfony/Component/DependencyInjection/Container.php#L197-L208

@dmaicher you should send a PR on https://github.com/craue/CraueFormFlowBundle/blob/2.1.9/Resources/config/form_flow.xml#L29 to add on-invalid="null"

But technically as long as I'm in request scope I will always be able to retrieve the request service. So adding on-invalid="null" should not be necessary imho as the service is marked with scope="request"?

Isn't this a BC break how the behaviour of the container changed for setting service instances to null will now trigger "re-instantiation"?

@fabpot @stof I'd be happy to have your input here:

1. when not leaving scope should synthetic services always throw and ignore the ContainerInterface::NULL_ON_INVALID_REFERENCE flag as is the case now (latest 2.7 and before)?
2. when leaving scope should synthetic services always return null and ignore the ContainerInterface::EXCEPTION_ON_INVALID_REFERENCE flag as it was the case before 2.7.10?

In both cases, this is untested behavior. This PR adds a test for 1.

I guess we should revert yes. This issue is gone on 3.0 since scopes are gone also.