TerminableInterface's terminate call happens before the response is sent

[bertrama]

I don't know that there's much to be done about this, but I noticed that the part implementing TerminableInterface in Bridges/HttpKernel.php (near line 98) runs ...->application->terminate() before sending the response rather than after.

This may be a problem with the underlying php-pm or react-php structure. I couldn't tell after my initial investigation where the right solution would live.

[andig]

I'm not sure why you think this is the case. In https://github.com/php-pm/php-pm-httpkernel/blob/master/Bridges/HttpKernel.php#L96 we're calling mapResponse() which actually sends the response- before calling terminate. When mapResponse() is called the Symfony response as already been received and sent from the applications persprective- the request is finished.

[bertrama]

In my testing I put asleep(5); call in application->terminate() and the response isn't sent to the browser until after those 5 seconds.

I dug around and made a global reference to the event loop and told it to ...->tick(); once before ...->application->terminate(); The response was sent, and then the ->terminate(); function was called. My intuition is that what we really want to do is to put an event into the event queue which will call ->terminate() it wasn't clear to me how to do that, I didn't think I had direct access to the event loop in php-pm.

[andig]

In my testing I put asleep(5); call in application->terminate() and the response isn't sent to the browser until after those 5 seconds.

I see- you're coming from a different angle. The response has been sent by the symfony application and the request is finished. It has however not been received by the browser.

I have not used the TerminableInterface before but I'm assuming that it does not imply "received by last downstream client"? Without php-pm that might e.g. mean received by some middle network component, even then not necessarily the browser?

I'd vote for leaving as is unless we can find a use case that actually breaks with the current implementation.