fix(serializer): preserve deserialization path and expected type on IRI type-confusion guard

[alexndlm]

Q	A
Branch?	4.3
Tickets	Closes #8352
License	MIT

Problem

The type-confusion guard in AbstractItemNormalizer::getResourceFromIri() throws a bare NotNormalizableValueException, which carries neither the deserialization path nor the expected type:

if (!$matchesType) {
    throw new NotNormalizableValueException(\sprintf('The iri "%s" does not reference the correct resource.', $data));
}

When COLLECT_DENORMALIZATION_ERRORS is enabled (the default for DeserializeProvider), DeserializeProvider::createViolationFromException() then builds a ConstraintViolation with an empty property path and an empty expected type, so the user-facing violation degrades to This value should be of type . with no property name.

Before #8333 the guard threw an InvalidArgumentException, which was caught a few lines below and re-thrown via NotNormalizableValueException::createForUnexpectedDataType(...) — preserving both the path and the expected type. #8333 changed the throw to a NotNormalizableValueException (so union/intersection denormalization can fall through to the next member) but stopped going through the factory, dropping that metadata for the single-type case. This is a regression vs 4.3.13.

POST a valid IRI that points to a resource of the wrong type for a relation:

POST /books
{ "title": "t", "printingHouse": "/publishing-houses/1" }

• 4.3.13: propertyPath: "printingHouse", Invalid IRI "/publishing-houses/1".
• 4.3.14: propertyPath: "", This value should be of type .

Fix

Keep the exception a NotNormalizableValueException (so the union/intersection fallback from #8333 / #8339 still works), but build it through createForUnexpectedDataType() so the deserialization path and expected type are preserved on the resulting violation.

Tests

• Unit: AbstractItemNormalizerTest::testTypeConfusionGuardPreservesPathAndExpectedType — denormalizes a wrong-type IRI and asserts the thrown NotNormalizableValueException keeps its message, path and expected type. Full AbstractItemNormalizerTest suite green (46 tests), including the testUnionType* fallback tests from fix(serializer): fix union types denormalization fallback after security mismatch #8333 / fix(serializer): accept union-typed IRI collections on denormalization #8339.

Note: the functional harness wouldn't boot in my local sandbox (kernel warmup fails on an unrelated mcp config in the fixture app). The unit test covers the precise denormalization path; CI validates the functional suite.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2715c78704

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[alexndlm]

Heads-up on CI: the failing jobs (PHPUnit (PHP 8.3) (Symfony lowest), PHPUnit api-platform/serializer (PHP 8.5 lowest)) are pre-existing on 4.3, not introduced here. On the base commit (be26bbe) the same single failure is present:

• UnionIriCollectionTest::testDenormalizeCollectionAcceptsIriOfEachUnionMember (added in fix(serializer): accept union-typed IRI collections on denormalization #8339) — Tests: 1957 … Failures: 1, identical on base and on this branch.
• AbstractItemNormalizerTest::testUnionTypeCollectionDenormalizationAcceptsAnyMember — base Tests: 105 … Errors: 1, this branch Tests: 106 … Errors: 1 (the extra test is the new passing one here).

On symfony/property-info lowest, context['relation_native_type'] is a legacy type rather than a TypeInfo\Type, so the union-collection guard falls back to is_a() against the first member and rejects a valid IRI for the second one. That is a pre-existing #8339 gap on the lowest stack, unrelated to this regression fix — this PR only changes the message text of that already-failing assertion (does not reference the correct resource. → Invalid IRI "…".). Happy to open a separate PR for the lowest-stack union-collection case if useful.

[soyuka]

Thanks!