any chance to bisect which PR broke this ?

This is a bit hard to bisect because we merge older branch.
git bisect tells me it 7a7165e
but obviously it's not that :(
I will try on a 3.4 project but I don't have such project.

If someone has this, I used the following script:

<?php

require __DIR__.'/vendor/autoload.php';

exec('rm -rf '.__DIR__.'/var/cache');

try {
    $k = new AppKernel('dev', true);
    $k->boot();
    $c = $k->getContainer();
} catch (\Exception $e) {
    exit(255);
}

$dataProviders = $c->get('api_platform.collection_data_provider');
if (iterator_to_array($dataProviders->dataProviders)[0] instanceof AppBundle\Api\DataProvider\AggregatedLogDataProvider) {
    exit(0);
}

exit(1);

and in vendor/symfony/symfony folder:

git bisect start && git bisect good v4.2.1 && git bisect bad v4.2.2 && git bisect run php ../../../test.php

well, is there a way to force bisect to identify the merge commit merging the issue ? All our changes happen through merges (from PR, or from older branches). That would restrict the list of impacted changes (if it is a branch merge, we would then have to check only the few PRs merged in by this particular merge)

just found https://github.com/dealertrack/merge-bisect which might help here.

I took a fresh 3.4 website-skeleton and added APIP on it.
I created a stupid DataProvider and run git bisect on it.
It could be e07ad2b // cc @nicolas-grekas
If I took v3.4.21 and revert this commit, the test is green

Yeah, setDefinition now removes the old definition entirely before adding the new one. So replacing a definition (when resolving ChildDefinition or decoration for instance) will now change the order of services (the service will move to the end).

Is it considered as a BC Break ? IMHO it should be because it breaks so many applications

Yes, let's revert that PR, it doesn't correctly fix the issue it was supposed to anyway. PR welcome.

Thanks @fabpot