PR verified on a website-skeleton, works as expected now IMHO.

Thanks for giving it a look :)

Writting to the server should not happen in a DumperInterface, that's not its semantics.

Well, I don't agree.DataDumperInterface is responsible for dumping theData objects. Either locally in current output, or remotely letting a server delegate then to another dumper; that's not transgressing this responsibility.
You may keep theConnection object though, if you think it needs to be decoupled from theServerDumper implementation, but theServerDumper is legit to me. This is the one ensuring seamless usage of the server dumper when the server is not up. To me, it's a better design than requiring to set a handler with specific code for handling the connection (the changes you made inDumpListener). It's a solution well-integrated within the component, so better at a global level.
Please consider theDumpDataCollector issue we encounter here is the edge-case from the component POV. Not the norm. Someone using the VarDumper component alone should be able to wire theServerDumper, IMHO with the current API.

To me, the culprit here really is theDumpDataCollector which has way too much responsibilities and hardcoded things.
We'd not have this issue if we had aDebugDumper (similar to the one proposed in#27397) that would have been set as the wrapped dumper of theServerDumper, and theDumpDataCollector only dealing with its role of collecting the dumps (maybe with the classicTraceableDumper decorator around the wired dumper, i.e the server dumper when wired or debug dumper directly otherwise).

DataDumperInterface is more for formatting than sending:HtmlDumper,CliDumper,JsonDumper,SerializerDumper,Base64SerializerDumper etc. these are all valid use cases for it. Since formatting needs an output medium, there is also an implicit concept ofwhere the formattedData should be written, by necessity. But this is a concept that is better separated from formatting. Maybe another name would have been better. The fact that the issue we're talking about exists at all is precisely the hint the interface has been misused to me. The fact also that by identifying this issue, this PR fixes it while removing lines of code is another hint.

the culprit here really is the DumpDataCollector which has way too much responsibilities and hardcoded things

So, I tried again keepingServerDumper as done right now: this just doesn't fit, at least not without a maybe heavy refactoring. You may be right, but not in this reality :)

at least not without a maybe heavy refactoring

Yes I also struggled with theDumpDataCollector (both when initially developing the feature and then with this issue). To me that's the hint it does too much.
I'd honestly prefer keeping the current API and work on#27397 to add the missing code fromDumpDataColector even if it means duplicating code, until we can consider refactoring the DumpDataCollector in 4.2 according to#27614 (comment) last paragraph. So no BC break and the feature keeps being part of the classic VarDumper API.

You may be right, but not in this reality

Hope you're wrong ^^'

I reverted the big BC break (there are still some minor on the edges, but this is required for the bugfix and OK for a.0 release IMHO.)

(failure will be fixed by a merge up to master)

@ogizanagi I don't reproduce this behavior :(
Can you try this patch?

                 stream_socket_shutdown($this->socket, STREAM_SHUT_RDWR);+                fclose($this->socket);+                $this->socket = false;

It works 👍

It works, but only on second request after re-uping the server. Note that commenting thecreateSocket in the constructor is fixing it (just an hint of course).

I removed the async flag + constructor connection, does it fix it?

No, it doesn't work at all now, unless you restore a timeout instream_socket_client too ("stream_socket_client(): unable to connect to tcp://127.0.0.1:9912 (Operation timed out)").

But honestly, if you want to give a try to async with previous version + patch above, I won't personally mind because I didn't reproduced on a different machine but with very similar env. We may reconsider if we have other reports. Or create another PR for async.

Pushed again, with your patch and the connection in the constructor removed.