fix(hydra): handle string and null serialization groups in DocumentationNormalizer

[Roemerdt]

Q	A
Branch?	4.3
Tickets
License	MIT
Doc PR

DocumentationNormalizer::getPropertyMetadataFactoryContext crashes when serialization groups are defined as a string rather than an array, or when no normalization/denormalization context is set.

Symfony's serializer supports string groups. AbstractNormalizer::getGroups() casts scalars to arrays, and the Symfony docs demonstrate the following is possible 'groups' => 'public_view'.

Reproducer:

#[ApiResource(
    normalizationContext: ['groups' => 'read'],
    denormalizationContext: ['groups' => 'write'],
)]
class DragonTreasure { ... }

Requesting the Hydra documentation endpoint produces:

• Warning: foreach() argument must be of type array|object, string given (string groups passed to foreach)
• Warning: Trying to access array offset on null (when context is null)

Fix:

• Wrap getNormalizationContext() / getDenormalizationContext() with ?? [] to handle null contexts
• Cast string group values to arrays before iterating, matching Symfony's AbstractNormalizer::getGroups() behaviour

[soyuka]

We should probably just type somewhere that our groups should be array shaped. I think there are other places in the code were we rely on that behavior.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[soyuka]

Confirmed as a real bug, and I have retargeted this to 4.4 and rebased it. 4.3 stopped at f35c53683 on 2026-09-12 and no longer receives fixes.

For the record, the case for the fix: DocumentationNormalizer is the only place that reads groups from the context without normalizing it. Three other places already do exactly what this pull request does:

• src/Doctrine/Orm/Extension/EagerLoadingExtension.php:87
• src/JsonSchema/DefinitionNameFactory.php:66
• src/JsonSchema/SchemaFactory.php:534

Symfony's own AbstractNormalizer::getGroups() casts a scalar too, so a bare string is supported input everywhere else in the stack. This is an internal inconsistency, not a sloppy configuration.

Two small things before it can go in:

1. The new test uses Prophecy. The project is moving off Prophecy, so new test code should use PHPUnit mocks ($this->createMock(...)), even where the surrounding file still uses prophesize().
2. There is a double blank line left after the two string casts. Running PHP_CS_FIXER_IGNORE_ENV=1 vendor/bin/php-cs-fixer fix will settle it.

Thanks for the patch and for your patience on the delay.

[Roemerdt]

Shall I pick up those two points or will you?

[soyuka]

Oh this was an agentic issue, I'll take care of this :) will be released today