Bug #101691


Symfony RawMessage - Fatal error: Uncaught Exception: Cannot traverse an already closed generator

Added by Bastian Stargazer 4 months ago. Updated 3 months ago.

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


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:
Actions #1

Updated by Bastian Stargazer 4 months ago

  • Tags deleted (symfony)

After testing an upgraded project from v10 to v11, we stumbled about a very strange error while sending mails via SMTP using TYPO3\Core\Mail\Mailer.

The first e-mail is sent out successfully (e.g. "User profile created" after submitting an application form). But sending out a second e-mail (e.g. another user applies through the form) resulting in the following error:

Fatal error: Uncaught Exception: Cannot traverse an already closed generator in /var/www/html/vendor/symfony/mime/RawMessage.php:52 Stack trace: #0 /var/www/html/vendor/symfony/mailer/Transport/Smtp/Stream/AbstractStream.php(112): Symfony\Component\Mime\RawMessage->toIterable() #1 /var/www/html/vendor/symfony/mailer/Transport/Smtp/SmtpTransport.php(206): Symfony\Component\Mailer\Transport\Smtp\Stream\AbstractStream::replace('\r\n.', '\r\n..', Object(Generator)) #2 /var/www/html/vendor/symfony/mailer/Transport/AbstractTransport.php(72): Symfony\Component\Mailer\Transport\Smtp\SmtpTransport->doSend(Object(Symfony\Component\Mailer\SentMessage)) #3 /var/www/html/vendor/symfony/mailer/Transport/Smtp/SmtpTransport.php(136): Symfony\Component\Mailer\Transport\AbstractTransport->send(Object(Symfony\Component\Mailer\SentMessage), Object(Symfony\Component\Mailer\DelayedEnvelope)) #4 /var/www/html/public/typo3/sysext/core/Classes/Mail/MemorySpool.php(110): Symfony\Component\Mailer\Transport\Smtp\SmtpTransport->send(Object(Symfony\Component\Mime\RawMessage), Object(Symfony\Component\Mailer\DelayedEnvelope)) #5 /var/www/html/public/typo3/sysext/core/Classes/Mail/MemorySpool.php(87): TYPO3\CMS\Core\Mail\MemorySpool->flushQueue(Object(Symfony\Component\Mailer\Transport\Smtp\EsmtpTransport)) #6 [internal function]: TYPO3\CMS\Core\Mail\MemorySpool->__destruct() #7 {main} thrown in /var/www/html/vendor/symfony/mime/RawMessage.php on line 52

If we clear the cache with cache:flush , one e-mail is sent again successfully, but the same error appears for the second e-mail.

We tried to track the issue down and find any mail-related things inside the cache, but there is nothing (at least not in form of strings). Maybe someone has more hints if we follow the stack-trace?

Symfony\Component\Mailer\Transport\Smtp\SmtpTransport.php => doSend()

line 206: In the foreach-loop, the $message->toIterable() is called. On the first call (sending the first e-mail)

Symfony\Component\Mime\RawMessage.php => toIterable()

line 52 is called. Because \is_string($this->message) is false, it continues with the loop to yield $chunk and sets the final string to $this->message = $message;


Symfony\Component\Mailer\Transport\Smtp\SmtpTransport.php => doSend()

the second time (sending second e-mail), it seems that the RawMessage object must be coming somewhere from the cache. But observing the Stack with XDebug did not help to determine a difference in both message objects (so we could not figure out where the second object came from exactly or how it is different from the first one).

Any help appreciated, also to provide further helpful details.

DDEV / Development mode
TYPO3 11.5.30
PHP 8.1

The described behavior only occurs if $GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_spool_type'] is set to "memory" (that might be the reason that we couldn't find anything related to the email message in the file-cache. Does cache:flush maybe flushes some PHP memory-cache?). Anyway, using the type "file" works like it should, so for now this is a potential workaround.

Just tested the issue outside of DDEV on a "real webserver", with the same results as described above.

Actions #2

Updated by Bastian Stargazer 3 months ago

Intermediate update: After endless hours of debugging it seems more and more like a project related issue. Still not sure how to dig further into it, since it is working with a simplified demo/testing implementation inside the same project! So it must have something to do with the (pretty complex) process in between.

I will further investigate and report here any findings in case it is an issue under certain conditions, or close the issue if it turns out to be not relevant.

@Garvin: highly appreciate your help!


Also available in: Atom PDF