clearChild() checks the parent's identifiers, so nulling a to-one relationship silently does nothing #30

PropertySetter::clearChild() reads its identifier list from the parent's resource definition, where its sibling removeAllChildrenExcept() correctly reads the child's.

The code

src/Resolvers/PropertySetter.php, in clearChild() (~line 274):

$existingChild = $this->getValueFromEntity($entity, $name, $parameters, $context);

// Don't remove any new entities
if (!$this->entityExists(
    $transformer,
    $existingChild,
    $field->getResourceDefinition()->getFields()->getIdentifiers(),   // <-- parent's
    $context
)) {
    return;
}

$this->clearChildInEntity($entity, $name, $parameters);

The same guard in removeAllChildrenExcept() (~line 344), applied to the same kind of subject — a child entity — uses:

$field->getChildResourceDefinition()->getFields()->getIdentifiers()   // <-- child's

$existingChild is a child entity, so its identity should be read from the child definition. Reading the parent's asks whether the child has the parent's identifier fields.

Consequence

When the parent definition declares no identifier, getIdentifiers() is empty, entityExists() returns false, and clearChild() returns early without doing anything.

Setting a to-one relationship to null therefore silently does not clear it. The write reports success and the old link stays.

It can also misfire the other way round when parent and child happen to declare identifiers of the same name but the child's real identity differs.

How it was found

Surfaced by the coverage work in #28, which had to give its fixture parent a declared identifier for testNullOnAOneRelationshipClearsIt to pass at all — the test notes this. Independently confirmed by reading both call sites.

Fix

Use $field->getChildResourceDefinition() in clearChild(), matching removeAllChildrenExcept().

Wants a regression test with a parent definition that declares no identifier, which is the case that currently fails, plus one covering the "genuinely new child is not cleared" behaviour the guard exists to protect — so the fix does not simply delete the guard's purpose.