[HttpKernel] Handle previously converted DateTime arguments
#46199
Conversation
src/Symfony/Component/HttpKernel/Controller/ArgumentResolver/DateTimeValueResolver.php
Outdated
Show resolved
Hide resolved
Can you elaborate on the side effects? I'm really not fond of patching Symfony to support a mix of param converters and argument value resolvers |
5fb1e88 to
a48ecb6
Compare
If your app already relies on them, then turning off the param converters (especially with #43854 not making it into 6.1) ends up being a much bigger refactoring. As much as I don't like the patch either, being a pragmatist here, I do think it solves the upgrade issue in a way that causes the least frustration for end-users (as otherwise you really either have to turn off the param converters and rewrite all controllers relying on those or mess with the container to remove one of the services to avoid the double-conversion issue), and this one condition can be re-evaluated or removed once we're at a version where both of the |
I thought it was in, thanks. |
|
Thank you @mbabker. |
I'm not sure I like this fix, but given the order of operations between the param converters in SensioFrameworkExtraBundle and the controller argument resolvers in the HttpKernel component, this is probably going to cause the least number of headaches for users when upgrading. And in some ways, this is the same problem as #40333 but in reverse.
Because the param converters are triggered on the
kernel.controllerevent, they will handle converting values before the controller argument resolvers are fired. This means that a typehintedDateTimeInterfacewill potentially be handled twice (once by the param converter, once by the argument resolver). To avoid theTypeErrornoted in the issue, a practical fix is to gracefully handle a previously converted value in this resolver. As the other options aren't great (removing services from the container or turning off the param converters in full, which has other side effects), this is probably the most practical fix.