Broken commit order in 2.6 #5988

New Issue

admin · 2026-01-22T15:24:08+01:00

admin commented

2026-01-22 15:24:08 +01:00

Originally created by @stof on GitHub (Jun 15, 2018).

Originally assigned to: @Majkl578, @guilhermeblanco on GitHub.

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.

Originally created by @stof on GitHub (Jun 15, 2018). Originally assigned to: @Majkl578, @guilhermeblanco on GitHub. ### 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.

admin added the Bug Failing Test labels 2026-01-22 15:24:08 +01:00

admin closed this issue

2026-01-22 15:24:08 +01:00

admin commented

2026-01-22 15:24:09 +01:00

@stof commented on GitHub (Jun 15, 2018):

@guilhermeblanco as you rewrote the CommitOrderCalculator in 2.6 (in https://github.com/doctrine/doctrine2/pull/1570), you may want to look at this issue

@stof commented on GitHub (Jun 15, 2018): @guilhermeblanco as you rewrote the CommitOrderCalculator in 2.6 (in https://github.com/doctrine/doctrine2/pull/1570), you may want to look at this issue

admin commented

2026-01-22 15:24:09 +01:00

@pestaa commented on GitHub (Jul 11, 2018):

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];

@pestaa commented on GitHub (Jul 11, 2018): 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: ```php 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]; ```

admin commented

2026-01-22 15:24:10 +01:00

@stof commented on GitHub (Aug 21, 2018):

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

@stof commented on GitHub (Aug 21, 2018): @guilhermeblanco have you had any chance to take a look at it ?

admin commented

2026-01-22 15:24:10 +01:00

@stof commented on GitHub (Sep 20, 2018):

@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 ?

@stof commented on GitHub (Sep 20, 2018): @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 ?

admin commented

2026-01-22 15:24:11 +01:00

@Majkl578 commented on GitHub (Sep 23, 2018):

Fixed in #7260.

@Majkl578 commented on GitHub (Sep 23, 2018): Fixed in #7260.

admin referenced this issue

2026-01-22 16:07:29 +01:00

[PR #7322] JoinedSubclassPersister pass identifier types on delete #10425

Sign in to join this conversation.