Persistence lost when accessing before flushing #65638

Your hunch at the bottom is right, this is Doctrine rather than Symfony, and it's working as designed even though the result is genuinely surprising.

$m1->getOneSides() is a lazy collection that hasn't been loaded yet. The moment you iterate it, Doctrine goes to the database to fill it, and the database still has o1 pointing at m1, because your change only exists in the unit of work and hasn't been written. So the query comes back with o1 in it. Doctrine then hydrates that row into the entity it already holds in the identity map, which is your $o1, and in doing so it re-establishes the owning side reference from what the database said. That quietly overwrites the $m3 you set a moment earlier.

Which is why flushing first makes it behave. After the flush the database agrees with memory, so the load can't contradict you.

The fix I'd reach for isn't ordering your calls carefully, because that's a rule you have to remember forever. It's keeping both sides of the association in sync in the entity itself, so the in-memory object graph is already correct and the lazy load has nothing to disagree with:

public function setManySide(?ManySide $manySide): static
{
    if (null !== $this->ManySide && $this->ManySide !== $manySide) {
        $this->ManySide->removeOneSide($this);
    }

    $this->ManySide = $manySide;

    if (null !== $manySide && !$manySide->getOneSides()->contains($this)) {
        $manySide->addOneSide($this);
    }

    return $this;
}

This is the part MakerBundle leaves to you on the owning side, and this scenario is more or less the reason it matters. contains() will trigger the same lazy load, but it happens while you're making the change rather than afterwards, so the collection ends up consistent instead of stale.

Worth noting the naming is going to confuse whoever reads this next, since ManySide is the class holding the OneToMany. Not your bug, but I'd rename before this grows.

If you do want to raise it somewhere, doctrine/orm is the repo, though I'd expect the answer there to be the same.