TestMailCollector is slow with lots of recipients

1. Tagging "Bug Smash Initiative"
2. Changing the target version to the current dev branch

Applying IS template

Form submission was taking too much time on our server (about 30 sec)

I don't understand how this is related to TestMailCollector. The TestMailCollector is used only in tests. It is unclear to me why this is considered a bug in Drupal core, since there is no mention of performance problems in core related to this.

If there is a performance problem in your own test cases for your own module that uses TestMailCollector, then I think the problem is with your code - the state system is perfectly suited for core's needs. However, if you are trying to send thousands of large emails in a test case then this implementation is not ideal - but why would you do that? And why would you not just subclass TestMailCollector or write your own mail collector plugin if you have specialized needs for your tests? And if you're saying that this is a problem with interactive use of your site and NOT tests, then why are you using TestMailCollector?

Without a test case demonstrating that this is a problem in core Drupal tests I would mark this as "won't fix".

See the content of the whole file: core/lib/Drupal/Core/Mail/Plugin/Mail/TestMailCollector.php

<?php

namespace Drupal\Core\Mail\Plugin\Mail;

use Drupal\Core\Mail\MailInterface;

/**
 * Defines a mail backend that captures sent messages in the state system.
 *
 * This class is for running tests or for development.
 *
 * @Mail(
 *   id = "test_mail_collector",
 *   label = @Translation("Mail collector"),
 *   description = @Translation("Does not send the message, but stores it in Drupal within the state system. Used for testing.")
 * )
 */
class TestMailCollector extends PhpMail implements MailInterface {

  /**
   * {@inheritdoc}
   */
  public function mail(array $message) {
    $captured_emails = \Drupal::state()->get('system.test_mail_collector', []);
    $captured_emails[] = $message;
    \Drupal::state()->set('system.test_mail_collector', $captured_emails);

    return TRUE;
  }

}

TestMailCollector is put in the wrong place from my understanding. Its name has a prefix "Test", but it's being invoked by the MailManager as a normal Mail plugin every time, so this is a BUG and unexpected to me.

The priority could be Major at least I think.

The fix could be moving it to a module like mail_test or somewhere else.

Setting back to NR.

Active, not NR. No patch here... But I would still say postponed or won't fix since the TestMailCollector works as designed and I don't see any justification for re-writing it.

I am very familiar with TestMailCollector - I have been using it for almost 7 years since it was first introduced by #2187495: Use plugin system for MailInterface classes. I've subclassed it when needed (e.g. to make an HTML-capable mail collector), and I've written other @Mail plugins that act as collectors but use strategies other than the state system to store data.

TestMailCollector is a @Mail plugin. But like all plugins is not used unless you specifically try to use it. Perhaps it should be in a test module rather than in the main Core tree, but it does what it is intended to do and it does exactly what it says it does - stores emails in the state system for use in testing and development. IMO if you want to use it in circumstances it was not designed for then that's a problem with how you're using it.

When the original poster mentions form submission, that tells me that the TestMailCollector is probably being used in a non-test environment. I don't know why that is being done, which is why I marked this issue as needs more information. But this seems to be a poor choice on the part of the initial poster. If the intent was to collect mails for later sending, then TestMailCollector is the wrong choice and an application-specific collector should have been written.