Looks like it is rated to the following PR: #48725

In our case we have 1.14.3 of doctrine/annotations installed so by understanding #48725 this error should not appear on this version. @derrabus do you maybe have a hint here for us whats going wrong?

Here also the first class which did error above: https://github.com/sulu/sulu/blob/5006f0bccfaf4a4f41ba3275e687263b4636e58b/src/Sulu/Bundle/MarkupBundle/Markup/Link/LinkConfiguration.php#L14-L21

It shouldn't, but it would still be nice to know if this still happens with the latest version of annotations though.

Unfortunately, I won't have much time to look into the issue this week (or the week after).

@derrabus I stripped it down and it is related when a bundle is already using registerFile in our case the ongr elasticsearchbundle. Which is doing that in our case here:

https://github.com/handcraftedinthealps/ElasticsearchBundle/blob/788d90fd5a753b832432d97a1b6fbd34ff3495a9/Mapping/DocumentParser.php#LL411C33-L411C45

In that case in 1.14.3 the class_exists is not longer called as this seems to disable the class_exists fallback here:

https://github.com/doctrine/annotations/blob/fb0d71a7393298a7b232cbf4c8b1f73f3ec3d5af/lib/Doctrine/Common/Annotations/AnnotationRegistry.php#L67

https://github.com/doctrine/annotations/blob/fb0d71a7393298a7b232cbf4c8b1f73f3ec3d5af/lib/Doctrine/Common/Annotations/AnnotationRegistry.php#L180-L181

And so it fails on Symfony 6.3 but not on Symfony 6.2.

I was not yet able to test doctrine/annotations:2 but based on the code I see it is only a bug with ^1.0 of doctrine/annotations not 2.0 as there seems class_exists always be called.

I think at current state I could also remove the registerFile from the Ongr Elasticsearch bundle and require doctrine/annotations: ^1.10: handcraftedinthealps/ElasticsearchBundle#34.

In that case the error seems not longer appear. Still its some kind of a unexpected bc break happening here when upgrading to Symfony 6.3, but happy already found the source and have a workaround possible now to avoid that issue.

Both JMS and FOSRest looks like not using registerFile and so that error does not appear when using only that packages. /cc @goetas is this correct that it expect autoload there?

Not sure if there are other bundles using annotations via registerFile which could break Symfony 6.3 support.

ping, all annotations stopped working:

[Semantical Error] The annotation "@Doctrine\ORM\Mapping\MappedSuperclass"   
    in class Gedmo\Tree\Entity\MappedSuperclass\AbstractClosure was never impor  
    ted. Did you maybe forget to add a "use" statement for this annotation?  

The annotation "@Sensio\Bundle\FrameworkExtraBundle\Configuration\Cache" in method App\Controller\UserController::autoLogoutAction() was never imported. Did you maybe forget to add a "use" statement for this annotation?

@derrabus ack, it does not happen with sf63 + doctrine/annotations:2

only one dep blocks it for us 😅 🙏

ping

Before pinging, have you read the previous comments, especially that one by @alexander-schranz: #50617 (comment) ?

yes

edit: right, i too found some vendor bundle that calls AnnotationRegistry::registerFile(

Can you please ask them to stop doing so? Alternatively, your workaround would be to add this line somewhere in your bootstrap logic:

AnnotationRegistry::registerLoader(class_exists(...));

I'm not sure if related, the past 2 days I've encountered issues loading annotations in my application. I get the error above for either doctrine entities, or validation annotations so far. I cannot reproduce this error anywhere.

I've had this happen on 4.4 and 5.4 in 2 different environments. In both scenarios it seems related to trying to build a cache that was originally generated via a cache warm-up on the CLI without opcache, while apache runs with opcache. Due to this happening in a production environment I have not been able to dive deep into the why, but a webserver restart fixes it for me, while a reload does not. I have doctrine annotations 1.14.3, and the framework bundle on v4.4.49 and v5.4.25. With v4 this happened with doctrine annotations on an entity for @Column and on @Entity for another (which is also weird..), with v5 I had this on @Assert\NotBlank.

🟥 service apache2 reload
✅ service apache2 restart

What I noticed is that in the cache pools there was no reference to the annotations whatsoever, despite doing a reload. After the restart it created the cache directories. This system works with symlinks though, and it wouldn't surprise me if it was a race condition between swapping the symlink and a realpath call or something, but I haven't been able to find anything conclusive.

The only common denominator here for me is doctrine annotations 1.14.3

I've had this happen on 4.4 and 5.4

The issue we're discussing here happens because of a change introduced in 6.3.

The only common denominator here for me is doctrine annotations 1.14.3

See if you can upgrade to v2.

I will try this somewhere next week if all goes well, currently still in the process of testing 4.4 -> 5.4 (2.0 depends on cache 5.4).

The issue we're discussing here happens because of a change introduced in 6.3.

Yes, due to getting the same type of error with the same shared package, I figured I'd add my issue in case it does happen to be related.

2.0 depends on cache 5.4

No, it doesn't. It uses Cache 5.4 internally for testing, but any PSR-6 compatible cache will do. Cache 4.4 implements PSR-6 already, so you should be good.

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

Could I get an answer? If I do not hear anything I will assume this issue is resolved or abandoned. Please get back to me <3