Make runTolerantSingleCommand protected?

[andreas-gruenwald]

If runTolerantSingleCommand() would be protected, then a custom error handling can be added for child processes.

[theofidry]

As per #20, I'm not sure there is much error handling that should be done in there. If you have some cases in mind though we can reconsider

[andreas-gruenwald]

Use Case 1: if there is an exception in one of then the children processes, then an error message will show up, the the remaining child processes continue. Is there a way, to control the other processes, e.g. to conditionally stop them, if one of the child processes dies with a severe issue?

See #20, that might be done using static variables, but that's probably a bad pattern?

Use Case 2: We use the ParallelizationTrait in Pimcore projects. Pimcore has its own logger. We want to add additional logging behavior in the runSingleTolerant() method, or optimize the error messages for a specific project. Also, the container handling in Pimcore is a bit different.

[theofidry]

Is there a way, to control the other processes, e.g. to conditionally stop them, if one of the child processes dies with a severe issue?

Not that I know of. Whilst it might be possible, I'm not sure it's a good idea since we are considering switching to AMPHP parallel which might not offer an API allowing this.

To me your cases screams better error handling support which I agree is a bit lacking and not too happy about it atm. I'm however not 100% sure how to do that yet... I suggest you do a PoC PR with all the changes for your use case and then maybe we can review what can be done. Maybe it would need some adjustements to be BC compliant or maybe it's going to be acceptable BCs for an RC or it will have to wait 2.x.

[theofidry]

In 2.x the method looks like this:

private function runTolerantSingleCommand(
        string $item,
        InputInterface $input,
        OutputInterface $output,
        Logger $logger
    ): void {
        try {
            ($this->runSingleCommand)($item, $input, $output);
        } catch (Throwable $throwable) {
            $this->errorHandler->handleError($item, $throwable, $logger);
        }
    }

So whilst no longer overridable, I believe the error handler should offer enough room for custom error handling.