I'm not sure about those... but we want to know if the "inversed" association is a collection here, if it exsts. It's the only way to know that we are handling an "inverse one to one"

I'm wondering if it is OK to return null here.
Can a "OneToOne" relationship be "not nullable" on the both sides of the relationship?

EDIT: I think it can:

#[Entity]
class Contact
{
    #[ORM\OneToOne(targetEntity: Address::class, inversedBy: 'contact')]
    #[ORM\JoinColumn(nullable: false)]
    public Address $address;

    public function __construct()
    {
        $this->address = new Address($this);
    }
}

#[Entity]
class Address
{
    public function __construct(
	    #[ORM\OneToOne(targetEntity: Contact::class, mappedBy: 'address')]
	    public Contact $contact;
    ) {}
}

and then, it would not be valid to return null here 🤷

I think this very specific case, where both side of OneToOne are mandatory, could not be fixed : it is a circular dependency. Maybe we could find a way to emit a meaningful error for the user?

Also, maybe we could find a way to return something else than null here: in Foundry2, we used to return a PostPersistCallback which was not added to the normalized parameters. Maybe we could mimic this (but it would complexify the whole normalization phase)

BTW, I just figured out that you did notice this case was error prone: https://github.com/zenstruck/foundry/blob/2.x/tests/Integration/ORM/EntityFactoryRelationshipTestCase.php#L183

Yes, I don't remember the exact context of what happened but I think you're right, it's the circular dependency issue.

need to fix this, to mimic how it is done with orm v3