Bug #93169


500 error, [CRITICAL] request="42945d6a42cae"

Added by Helmut Winkelbach over 3 years ago. Updated about 3 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


After upgrade from 10.4.9 to 10.4.12 i got the following error:

Fri, 25 Dec 2020 09:17:28 +0100 [CRITICAL] request="42945d6a42cae" component="TYPO3.CMS.Core.Error.ProductionExceptionHandler": Core: Exception handler (WEB): Uncaught TYPO3 Exception: Expected to find class "TYPO3\CMS\Core\Context\FileProcessingAspect" in file "/var/www/" while importing services from resource "../Classes/*", but it was not found! Check the namespace prefix used with the resource. | Symfony\Component\DependencyInjection\Exception\InvalidArgumentException thrown in file /var/www/ in line 206. Requested URL: - {"TYPO3_MODE":"BE","exception":"Symfony\\Component\\DependencyInjection\\Exception\\InvalidArgumentException: Expected to find class \"TYPO3\\CMS\\Core\\Context\\FileProcessingAspect\" in file \"/var/www/\" while importing services from resource \"../Classes/*\", but it was not found! Check the namespace prefix used with the resource. in /var/www/\nStack trace:\n#0 /var/www/ Symfony\\Component\\DependencyInjection\\Loader\\FileLoader->findClasses('TYPO3\\\\CMS\\\\Core\\\\', '../Classes/*', Array)\n#1 /var/www/ Symfony\\Component\\DependencyInjection\\Loader\\FileLoader->registerClasses(Object(Symfony\\Component\\DependencyInjection\\Definition), 'TYPO3\\\\CMS\\\\Core\\\\', '../Classes/*', NULL)\n#2 /var/www/ Symfony\\Component\\DependencyInjection\\Loader\\YamlFileLoader->parseDefinition('TYPO3\\\\CMS\\\\Core\\\\', Array, '/var/www/vhosts...', Array)\n#3 /var/www/ Symfony\\Component\\DependencyInjection\\Loader\\YamlFileLoader->parseDefinitions(Array, '/var/www/vhosts...')\n#4 /var/www/ Symfony\\Component\\DependencyInjection\\Loader\\YamlFileLoader->load('Services.yaml')\n#5 /var/www/ TYPO3\\CMS\\Core\\DependencyInjection\\ContainerBuilder->buildContainer(Object(TYPO3\\CMS\\Core\\Package\\PackageManager), Object(TYPO3\\CMS\\Core\\DependencyInjection\\ServiceProviderRegistry))\n#6 /var/www/ TYPO3\\CMS\\Core\\DependencyInjection\\ContainerBuilder->createDependencyInjectionContainer(Object(TYPO3\\CMS\\Core\\Package\\PackageManager), Object(TYPO3\\CMS\\Core\\Cache\\Frontend\\PhpFrontend), false)\n#7 /var/www/ TYPO3\\CMS\\Core\\Core\\Bootstrap::init(Object(Composer\\Autoload\\ClassLoader))\n#8 /var/www/ {closure}()\n#9 {main}"}

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #93134: Exception\InvalidArgumentException class FileProcessingAspect not foundClosed2020-12-21

Actions #1

Updated by Riccardo De Contardi over 3 years ago

Hi can you give more details? For example which steps did you follow to update TYPO3?

I performed an update 10.4.9 > 10.4.12 using composer and did not have this error.

Actions #4

Updated by Helmut Winkelbach over 3 years ago

after changing the symlink i could see the login page for a second and the error appeared.
After deleting var/cache the same, 1 second login page the error appeared.

Actions #5

Updated by Riccardo De Contardi over 3 years ago

so far, I have understood that you are using the "plain" installation method with symlinks;

I assume you have already tried to perform deep cache cleaning and dump autoload from the Install Tool...

Actions #6

Updated by Michael Sollmann over 3 years ago

Can confirm this.
It seems that on some servers we have to delete the old sources to get the error gone.

Related to

Actions #7

Updated by Christian Weiske over 3 years ago

  • Related to Bug #93134: Exception\InvalidArgumentException class FileProcessingAspect not found added
Actions #8

Updated by Thomas Sperling about 3 years ago

I had the same problem. Deletion of old source did not work.
I had to call opcache_reset(); manually.

Actions #9

Updated by Christian Kuhn about 3 years ago

  • Status changed from New to Closed


Thanks for your feedback on this.

When DI changes between versions, it may result in backend fatals. Dropping typo3temp/var/cache/code should help.

For patch level upgrades in non-composer mode done via the install tool, this is done automatically, the DI cache can also be cleared in the install tool with 'clear all cache' which also resets opcode, if possible.

opcache is by default configured to detect file changes automatically, so usally, a manual reset isn't required. Still, core has some places to do that automatically at some places. However, if your hosting is configured to not detect file changes in opcache automatically, it may depend on your deployment strategies if you need to trigger this within your deployment scripts.

I think there isn't much we can do at the moment in core. I'll go ahead and close this issue for now. Please open a new one if you think there is something left to do.


Also available in: Atom PDF