fix: resolve union in types

[Cafeine42]

Q	A
Branch?	4.3
Tickets	Regression from commit 6bcbeb2 / advisory GHSA-9rjg-x2p2-h68h
License	MIT
Doc PR	N/A

Affected versions

• Works: v4.3.10
• Broken: v4.3.13 (regression introduced by 6bcbeb2db)

is_a guard from 6bcbeb2 breaks union-typed collections

The security fix in 6bcbeb2db (GHSA-9rjg-x2p2-h68h, v4.3.13) added an is_a() guard in AbstractItemNormalizer::getResourceFromIri() (src/Serializer/AbstractItemNormalizer.php:762). It's too strict for union-typed collections like array<Foo|Bar>.

Cause: in createAndValidateAttributeValue() each candidate type is tried in turn. The guard makes denormalizeObjectCollection() throw on the first item that doesn't match the single type being tried. Foo[] fails on the first Bar, Bar[] fails on the first Foo, so no iteration can succeed. The error is then re-wrapped at the collection level (path items) instead of item level (items[2]).

Impact:

1. Error-message regression — the precise invalid index is lost.
2. Functional regression — a legitimately mixed collection (e.g. [foo, foo, bar]) is now systematically rejected.

Affected: works in v4.3.10, broken in v4.3.13.

Suggested fix: make the is_a guard union-aware — pass all possible union types to the check, or preserve the item-level error path. The security fix itself must be kept.

Reproduce

1. Entity with a property typed array<Foo|Bar> exposed via API Platform.
2. POST/PATCH a collection with a type mismatch (or a legitimate mix).
3. v4.3.10 → error scoped to items[2]; v4.3.13 → whole collection rejected.