Tobias

I've added a test that triggers the assertion in debug builds even if pipelining is enabled. https://github.com/vapor/http/blob/939d1f93bcda7ad5295f1c2745d2eb962e63c2d7/Sources/HTTP/Responder/HTTPServer.swift#L150

If you enable the `pipeliningAssistance` of swift-nio the responses arrive in the correct order! ```swift // configure the pipeline return channel.pipeline.configureHTTPServerPipeline( withPipeliningAssistance: true, /*false*/ withServerUpgrade: upgrade, withErrorHandling: false ``` [HTTPServer...

Here is a test case that shows this problem: ```swift func testPipelining() throws { struct SlowResponder: HTTPServerResponder { func respond(to request: HTTPRequest, on worker: Worker) -> EventLoopFuture { let timeout...

Hello, is anybody acknowledging this issue? Am I missing something? It seems pretty serious to me. Especially with a service under load.

Thanks @tanner0101 for the write-up. I'm still a bit worried about my micro service running on the current Vapor 3 HTTP server without pipelining. As it is a micro service,...

Super, looks good to me. I've just opened #321 to add a test case for pipelining.

Is there some progress?

Just dropping an idea here: If I read the current implementation correctly the lambda runs mostly "on the main thread" and `.wait()`s on the futures of the event loop from...

Ah yes, actually this is pretty much what I had in mind. In the end we would need to do some profiling to see where the swift code spends too...

Have you benchmarked @fabianfett's implementation as well?