My first question to you would be: where is track_errors used? Is it in a third party extension?

It's a default php.ini option provided by PHP itself and is deprecated since PHP 7.2. This means if this option is used, even if set to Off the deprecation message is shown.

But the same can occur anytime for any other deprecation in PHP.

Since PHP outputs this startup error message early on, before any php script is triggered and it output this message to stdout not stderr, I see no way to fix this particular issue.

Other notices triggered during runtime are either muted by our own error handler or the one from TYPO3, so they won't appear in the output. That is at least my observation.

If you have a way to reproduce a failure with runtime error messages, please let me know.

I also have no other idea how to let a subprocess cleanly communicate to the parent process, except from the hacky approach to use stdout for that. If you know from other ways to achieve that, let me know as well.

A safe solution would be a separate file descriptor instead of stdout but I'm not sure Symfony Process supports this.

Aside from that the only option I see ATM is to drop everything from the subprocess output except of the last line which is supposed to contain the actual output:

• Subprocess output:

  Deprecated: ...
  
  Deprecated: ...
  
  <serialized-string>
  

• After sanitation:

  <serialized-string>
  

separate file descriptors are not supported by Symfony Process

Regarding sanitation: I have no clue how we should detect what should be kept and what should be discarded

Maybe I'm naive but basically like this:

$output = $this->commandDispatcher->....;
$sanitizedOutput = array_pop(explode("\n", $output));

return $sanitizedOutput;

your code would cover exactly one case where exactly one line is prepended to the output. I'm not even sure if it would work on Windows (crlf)

Actually it works for many lines.

Well, ok it is the other way around. Only one output line is treated as valid, leading to a wrong result if the serialized string contains newlines. See the result of this code with an actual value produced by a subprocess.

We would need to wrap the actual output between magic strings and then cut out that value from in between.

And still, if this magical string would appear within the actual output it would break.

Guess we'd actually need a way to stop PHP from emitting these messages in subprocesses ...

This means if this option is used, even if set to Off the deprecation message is shown

I can't confirm, that the message appears when the option is set to off. Can you re-check? Thanks.

It does not appear, if track_errors is On, but display_errors is Off
It does not appear, if track_errors is Off, but display_errors is On

Therefore, I think, I have found a good solution to fix this.
Can you check whether #752 works for you?