symfony: `Route` attribute can not be used on `__invoke()` methods in invokable actions anymore

Symfony version(s) affected

6.2.0

Description

An automated update of https://github.com/symfony/framework-bundle/compare/v6.1.7...v6.2.0 broke all invokable actions:

CleanShot 2022-12-02 at 11 07 35@2x

Unless I forgot to read, this change is neither documented in release notes nor in the documentation.

What is the purpose of this obviously breaking change?

How to reproduce

Invokable action with attribute on `__invoke():

<?php

final class FooAction
{
    #[Routing\Annotation\Route(
        path: '/foo/',
        name: 'foo,
        methods: [
            HttpFoundation\Request::METHOD_GET,
        ],
    )]
    public function __invoke(): HttpFoundation\Response
    {
        // ...
    }
}

Possible Solution

Move attribute to class level.

#[Routing\Annotation\Route(
    path: '/foo/',
    name: 'foo',
    methods: [
        HttpFoundation\Request::METHOD_GET,
    ],
)]
final class FooAction
{
    public function __invoke(): HttpFoundation\Response
    {
        // ...
    }
}

Additional Context

No response

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 17 (17 by maintainers)

Most upvoted comments

@localheinz first, this has nothing to do with changes in FrameworkBundle (the code that triggers the error is in HttpKernel). And we are talking about a PHP regression that is already fixed in PHP since several patch versions. If you consider that being affected by an already solved bug is a BC break that we need to fix, the pre-requisite would be to have a CI setup running Symfony tests against all previous patch releases of PHP as well, not only the latest version (otherwise we are not able to make such guarantee as we would not even know that). That’s quite an insane setup to me.

And again, we have no way to add the conflict rule in the 6.2.0 release (time travel would be a prerequisite for that). And adding this conflict rule in 6.2.1 would make things worse instead of better (it would not forbid you to install 6.2.0 and be affected by the PHP bug, but would forbid you from benefiting from other Symfony improvements, and it will even forbid you to workaround the bug by moving away from __invoke if you cannot update PHP while staying on an uptodate version of Symfony).

And last thing: if you really care about compatibility with older patch releases of PHP itself, you can still spend your time to find a different implementation for the feature that does not trigger the PHP bug (while still not being able to forbid regressions on that as the CI would not run the broken PHP version). But I definitely won’t dedicate my free time to that work.

stof on Dec 2, 2022

Would it make sense to declare conflict with PHP 8.1.6-8.1.9?

ostrolucky on Dec 2, 2022

@stof

But why would I need to update the PHP version that I currently use?

Everything worked fine when using symfony/framework-bundle:6.1.7. The update to symfony:framework-bundle:6.2.0 broke my app.

Perhaps the platform requirement in composer.json needs an update?

It would be new to me that - when updating a single composer dependency - it is perfectly normal for everyone to also update the PHP version. If the composer dependency required a newer PHP version, that should be a hard requirement of said dependency in its composer.json, in my opinion.

localheinz on Dec 2, 2022