symfony: Autoloading broken with 4.4.31/5.3.8

Update: thanks for reporting this issue. We’re aware of it and we think we found the cause. We’re working on a fix and we hope to fix this very soon. Thanks!

I’ve just created the missing tags to ensure a smoother upgrade for everyone. So, a “simple” composer up should work everywhere now.

Update: apparently, the four faulty components (Messenger, Mailer, Notifier and Translator) have been fixed and we’re starting a new release process. Hopefully this will be fully fixed in just a few minutes. Thanks!

Thanks should go to Fabien and Nicolas who actually worked on fixing this problem! (and Alexander and others from the Core Team for alerting us early and for managing all the duplicated issue reports) And thanks to all the community for the quick reportings and all your feedback during the resolution process.

While everyone is working on a bugfix release for this, you can skip this version with a conflict instruction in your composer.json

{
    "conflict": {
        "symfony/translation": "v5.3.8",
        "symfony/mailer": "v5.3.8",
        "symfony/notifier": "v5.3.8",
        "symfony/messenger": "v5.3.8"
    }
}

The new 4.4.* version has been released. Please, run composer update again if you use that branch.

The 5.3.* version will follow very soon.

How did automated tests not catch this? 🤔

Fixed now

After delete composer.lock and the vendor folder it worked.

So everyone: don’t just run composer update. That the steps:

1 - delete vendor folder. 2 - delete composer.lock file. 3 - run composer update.

And they worked out.

The new 4.4.* version has been released. Please, run composer update again if you use that branch.

The 5.3.* version will follow very soon.

4.4.32 and 5.3.9 are intended to fix it, which is your exact version?

This issue affects to Messenger, Mailer, Notifier and Translator (all of them have bridges). We’ve fixed the problem and we’re force pushing those four repositories, so this should be fixed in just a few minutes.

~If things go as expected, there’s no need to remove the 4.4.31 and 5.3.8 releases or re-release them. They will work again when the repositories are re-pushed.~

But really, if you’re still using Composer 1 consider upgrading to Composer 2 using composer self-update --2 first.

It makes fixing issues quicker, it makes downloading anything quicker and it saves the planet a bit better than Composer 1.

Final? update: this seems to have been fixed. Please update to get the latest versions:

• https://github.com/symfony/symfony/releases/tag/v4.4.32
• https://github.com/symfony/symfony/releases/tag/v5.3.9

If there’s some persisting cache issues, you can try running composer clear-cache or even removing the entire vendor/ directory and installing dependencies again. But that shouldn’t be necessary for most people.

@javiereguiluz were the tests added to cover this situation in the future?

I had to clear composer cache with composer clearcache to get it working

The new 4.4.* version has been released. Please, run composer update again if you use that branch.

The 5.3.* version will follow very soon.

Didn’t worked out:

    "conflict": {
        "symfony/symfony": "*",
        "symfony/translation": "v4.4.31",
        "symfony/messenger": "v4.4.31",
        "symfony/mailer": "v4.4.31",
        "symfony/notifier": "v4.4.31"
    },

On old Laravel projects… Seems like some quality checks are missing…

I got issue also with symfony/notifier, the full conflict that works:

    "conflict": {
        "symfony/symfony": "*",
        "symfony/translation": "v5.3.8",
        "symfony/messenger": "v5.3.8",
        "symfony/mailer": "v5.3.8",
        "symfony/notifier": "v5.3.8"
    },

Please note that the most recent 4.4 version is 4.4.32 (https://github.com/symfony/symfony/releases/tag/v4.4.32) but Composer/Packagist cahce might still install 4.4.31 for you.

Yes, the broken packages have been removed from packagist.

There is no new release of symfony/translation for v4.4 yet.

Those commits doesn’t have this problem in the main repo, it looks like there is a problem in the subtree split process.

I think this is indeed a part of the issue.

We’re locking this issue because the problem was solved. If you still have issues, you can ask in the #support channel of https://symfony.com/slack or in the Symfony Discussions at GitHub

---

Problem

There was a temporary problem related to class autoloading of some Symfony components. The problem is now fully fixed.

Solution

If you use Composer 2, run composer update in your project

If you use Composer 1, run composer clear-cache and composer update If it doesn’t work, remove the contents of the vendor/ directory and run composer install If it still doesn’t work, consider upgrading to Composer 2 (you only have to run this command: composer self-update --2)

Api-platform while composer update fails with “* does not comply with psr-4 autoloading standard. Skipping.”. It attempts to install symfony/translation (v5.3.8)

That was unexpected and painful lol

Sadly, PHPUnit/Symfony tests don’t matter in this case. It was a bug related to the release process (the actual splitting of the Symfony monorepo into hundreds of stand-alone packages and pushing them to GitHub).

don’t you think that 5.3.8 tag should be removed from the list of releases until the issue will be fixed to decrease the bug effect?