TYPO3 Core

• I have a composer based installation
• I cleared all caches in the Backend > Admin Tools > Maintenance > Flush cache and also on command line with `vendor/bin/typo3 cache:flush`
• I also run `composer dump-autoload`
• I have the same issue on 2 different composer based TYPO3 12 installations
• Both installatiosn run inside an ubuntu docker container on a Windows 10 developer maschine

The error still exists.

Hi!

Can you tell some more specifics about your installation, especially how your TYPO3_CONF_VARS['MAIL'] is set?

Are you able to reproduce this in a vanilla composer installation without extension and customizations?

To me this sounds like either a problem with composer autoloading or with the way how a middleware or something else tries to access the Mailer, which might be related to custom code.

Are you maybe able to share your docker container for inspection?

I made now a complete fresh installation with `composer create-project "typo3/cms-base-distribution:^12.4" my-new-project` in a ubuntu docker container on the same Windows 10 developer maschine and there it runs now fine. No error. Okay. I need to investigate my existing development installations. I need to check my mail configuration.

Alright, thanks for the feedback - yes, first I'd check your MAIL config setup, and next all possible middlewares and custom event listeners. Hope you can investigate, let us know.

You seem to be using a specific Memory Spooler for Mails, maybe the classloading here doesn't work properly. I don't know though which specific 12.4.16 commit could've influenced the DI/autoloading here.

Finally I found the issue. It has nothing to do with my custom code. This error happends, if you configure `TYPO3_CONF_VARS\MAIL\transport_spool_type = memory` instead of no configuration.

Throws the error "Uncaught Error: Cannot instantiate interface TYPO3\CMS\Core\Mail\MailerInterface in /var/www/html/vendor/typo3/cms-core/Classes/Utility/GeneralUtility.php:2985"

<?php
return [
        'transport_spool_type' => 'memory',
    ],
];

Runs fine

<?php
return [
        'transport_spool_type' => '',
    ],
];

For me, this looks like a bug in the TYPO3 source. Maybe this setting is outdated and should not be configured. But it is still in the "Configure Installation-Wide Options" together with the options: file, memory or <classname>.

I also check the TYPO3 version 12.4.15 and 12.4.14 and there is the same error.

I believe the problem is that in the Install Tool > Environment, the framework doesn't really utilize Dependency Injection "properly", because it's in failsafe-mode.

Since probably utilizing "real DI" in this case won't work as intended, I'm afraid the fix might be to prevent calling the __destruct() method and sending mails when being inside the install tool context will very likely fail.

Here's a patch that would circument this, but I'm not sure in which cases the MemorySpool Mailer is currently broken, too. Maybe you want to check if regular mails still get sent with the patch applied (I think so).

Personally, I think the MemorySpool Mailer is not a good idea. It can easily lose mails. I'd strongly suggest to either use no spooler at all (and use a satellite mail relay on localhost) or the file spooler, which doesn't use __destruct logic.

diff --git a/typo3/sysext/core/Classes/Mail/MemorySpool.php b/typo3/sysext/core/Classes/Mail/MemorySpool.php
index 5fee22ddba..a275d307ec 100644
--- a/typo3/sysext/core/Classes/Mail/MemorySpool.php
+++ b/typo3/sysext/core/Classes/Mail/MemorySpool.php
@@ -69,7 +69,13 @@ class MemorySpool extends AbstractTransport implements SingletonInterface, Delay
     public function __destruct()
     {
         // TODO: DI should be used to inject the MailerInterface
-        $mailer = GeneralUtility::makeInstance(MailerInterface::class);
+        try {
+            $mailer = GeneralUtility::makeInstance(MailerInterface::class);
+        } catch (\Throwable $exception) {
+            // Install Tool has no DI setup. Thus also $this->logger is not usable here. Just bail.
+            return;
+        }
+
         try {
             $this->flushQueue($mailer->getRealTransport());
         } catch (TransportExceptionInterface $exception) {