Should it fail silently? I think it should result in a HTTP 400 status code.

In my API, I have a NotBlank constraint on the property which satisfies that.

In my API, I have a NotBlank constraint on the property which satisfies that.

This is always the same issue (I guess) :p. What if you don't have such constraint?

Either way, I don't think the normalizer should silently ignore a null value that it cannot set as requested. It should throw an exception. It's then up to the calling code to handle it, and in API Platform we should make sure that it (eventually) becomes a HTTP 400...

@soyuka

This is always the same issue (I guess) :p. What if you don't have such constraint?

then you'll have a database violation on insert.

@teohhanhui that seems like a nice solution.

Either way, I don't think the normalizer should silently ignore a null value that it cannot set as requested. It should throw an exception. It's then up to the calling code to handle it, and in API Platform we should make sure that it (eventually) becomes a HTTP 400...

Issues stays the same when you'd expect a ConstraintValidation instead of a Normalization exception :). And we will not change the listeners order (as discussed in other issues that I'm lazy to look up right now :p).

either way it needs to be handled somehow. at the moment a 500 isn't really acceptable.

A 400 should be thrown. Actually, Symfony's ObjectNormalizer should already throw in this case because if this check: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Serializer/Normalizer/AbstractObjectNormalizer.php#L342

We need to figure out why it's not the case.

https://github.com/bendavies/core/blob/3490493718982044420b98335787f40fabdfb4e6/src/Serializer/AbstractItemNormalizer.php#L230 should already trigger an error :|

php > var_dump(is_int(null));
bool(false)

@dunglas i'll take a look.

@dunglas

1. https://github.com/symfony/symfony/blob/cb2a77b24bc01a08787fcf9b4700fd5e03884155/src/Symfony/Component/Serializer/Normalizer/AbstractObjectNormalizer.php#L297
   $this->propertyTypeExtractor is null, so the below is never evaluated. bug in service def?
2. https://github.com/bendavies/core/blob/3490493718982044420b98335787f40fabdfb4e6/src/Serializer/AbstractItemNormalizer.php#L230
   the issue here is the doctrine type specifies nullable=true, but the setter does not allow null. the doctrine extractor takes precedence?

1. Yes it's intended, we overrode this logic by our own metadata system
2. Ok, so it's not really a bug, indeed the Doctrine extractor takes precedence. It should be fixed on Symfony side (but IMO the best is to fix the code).

Mutators should be in sync with the Doctrine mapping. To get the intended behavior I would:

• Make the setter accept null values
• Add a @NotNull validation assertion on the property

ok, sorry the actual problem is for non nullable resources relations, and passing in null.

setFoo(Foo $foo)

...

{"foo": null}

This will trigger a 500, as there is no nullable check here:
https://github.com/api-platform/core/pull/1911/files#diff-3e45e8e6ce08f8a7cbbbda1601d5ff29L197

Ok, we should throw in this case.

thanks, i'll work on this.

@dunglas what should i be throwing here? Is there currently a handler that converts whichever exception it is to a validation error?

ahh, ApiPlatform\Core\Exception\InvalidArgumentException returns a 400.

What's the status on this @bendavies ?

wow old one...no idea.
i'll take a look next week.

ahh, ApiPlatform\Core\Exception\InvalidArgumentException returns a 400.

We should throw Symfony\Component\Serializer\Exception\UnexpectedValueException instead.

@bendavies Up is this pull request still valid?

Closing this PR because it's too old and I can't reproduce.

this will be resolved by symfony/symfony#42502