Broken commit order in 2.6

[stof]

BC Break Report

Q	A
BC Break	yes
Version	2.6

Summary

Commit order is wrong in some cases, leading to broken inserts (inserting without the id for the foreign key). this is dependant on the order of persist() calls.

Previous behavior

Flushing was working fine

Current behavior

Flush is failing by trying to insert NULL in a non-nullable foreign key (probably planning to update the field later).

How to reproduce

See #7260 which provides some tests reproducing the issue.

[stof]

@guilhermeblanco as you rewrote the CommitOrderCalculator in 2.6 (in #1570), you may want to look at this issue

[pestaa]

When both the vertex and the adjacent vertex are in progress, the adjacent vertex might get added to the sorted node list, even though it could have other non-visited dependencies.

It gives correct results if you first sort vertex dependencies by descending weight:

    private function visit($vertex)
    {
        $vertex->state = self::IN_PROGRESS;

        $dependencyList = $vertex->dependencyList;
        usort($dependencyList, function ($a, $b) {
            return $b->weight <=> $a->weight;
        });

        foreach ($dependencyList as $edge) {
            $adjacentVertex = $this->nodeList[$edge->to];

[stof]

@guilhermeblanco have you had any chance to take a look at it ?

[stof]

@guilhermeblanco I think that when reaching an in-progress node, instead of adding it immediately in the list, we might want to trigger the processing of its own dependencies which are not yet in progress (in case we reached the cycle through the first dependency, and so second dependency was not processed yet). Does it look sensible to you ?

[Majkl578]

Fixed in #7260.