Thanks for reporting this issue, @NanoSector!

I was unable to reproduce it on an Ubuntu 24.04 installation running PHP 8.3. I tested using the following commands:

phpcs test.php test2.php --parallel=2
phpcbf test.php test2.php --parallel=2

Both PHPCS and PHPCBF worked as expected. I was also able to confirm using Xdebug that pcntl_waitpid() returns the correct PIDs. Is there anything unique to your environment that might help explain why pcntl_waitpid() is not returning the expected values? Are you able to test this on a different machine/environment to see if you can reproduce it?

As a side note, the example you provided (phpcs test.php test.php --parallel=2 - note that the command is passing the same file twice) uncovered what I believe to be another issue. I reported it here: #1113.

Thanks @rodrigoprimo, I'm not really sure what is causing this either, I hadn't looked into it that far. My assumption is that a PHP extension is starting a thread (maybe XDebug?) for some reason as there's no code preceding the phpcbf/phpcs execution.

The Ubuntu 22.04 machine in question is a slightly modified Laravel Homestead VM, but I understand that's a bit much to ask to setup to try to reproduce this issue.

I'll try to reproduce it on my personal MacBook later tonight, if I can't reproduce it there I'll make a dump of loaded php modules and PHP's ini values and compare the two, in that case I'll get back to you tomorrow.
But I highly doubt the underlying issue stems from phpcs, I think it's just exhibiting symptoms, the fix seemed small enough to report here.

Funny how this uncovered another issue 😅 I was fairly positive that I changed the file names appropriately.

@NanoSector I look forward to seeing the more detailed environment info tomorrow. I kind of doubt it will be related to Xdebug, as Xdebug is used a lot and I've not seen this issue reported before, but definitely curious to see what is causing it.

I dug a little deeper, turns out it is not a PHP environment issue but a side effect of a helper command I use to talk to the Vagrant VM from the host, written in Fish.

It eventually executes the following command:

ssh -o LogLevel=QUIET -t vagrant@192.168.56.56 -p 22 "bash --init-file <(echo \"cd /home/vagrant/projects/my-project\") -t -c \"vendor/bin/phpcbf --parallel=8\""

Running the following in the VM itself does not exhibit this behaviour:

bash --init-file <(echo "cd /home/vagrant/projects/my-project") -i -t -c "vendor/bin/phpcbf --parallel=8"

And moving the cd call into the -c argument also does not exhibit this behaviour:

ssh -o LogLevel=QUIET -t vagrant@192.168.56.56 -p 22 "bash -t -c \"cd /home/vagrant/projects/my-project && vendor/bin/phpcbf --parallel=8\""

What I think is happening is that Bash is somehow putting the file redirection into the same process group as phpcbf and this trips up the Runner. The in-VM implementation does file redirection before invoking bash with phpcbf.

This bug can be triggered from Bash without SSH by the following command:

bash -c 'bash --init-file <(echo "cd /home/vagrant/projects/my-project") -i -t -c "vendor/bin/phpcbf --parallel=8 -p"'

I do feel like phpcs/phpcbf should at least check that it's monitoring its own processes / ignore foreign processes, regardless of this unusual use case.

@NanoSector Interesting case for sure. Would there be any way this can be triggered without your custom Vagrant VM set up though ?

@jrfnl Yes, you should be able to trigger it locally using the last command I provided (replace the path with something pointing to a project with phpcs in it). This works on my MacBook without any VMs involved.