Remove '__disable_customize__' parameters while queuing legacy emails

Thanks for reporting the issue. I think the proposed change is not correct because the parameter is used to handle emails differently when sending them. See the comments in Drupal\symfony_mailer\Mailer::doSend().

I am confused, though, about how legacy emails are queued at all. This should only be the case when using the "Queue sending" email adjuster. Can you please post the steps to reproduce the issue? Or describe in more detail how you are sending legacy emails?

Patch doesn't work.
Module doesn't work on D11.

@trickfun Can you please add some more details about your installation and the exact issue your are facing?

Hi simonbaese,
here new information

ResponseText: The website encountered an unexpected error. Try again later.Error: Unknown named parameter $__disable_customize__ in Drupal\symfony_mailer\EmailFactory->initEmail() (line 92 of modules/contrib/symfony_mailer/src/EmailFactory.php). Drupal\symfony_mailer_queue\Service\EmailFactory->newTypedEmail('easy_email', 'user_password_recovery', Array, 1) (Line: 87)
Drupal\symfony_mailer_queue\Plugin\QueueWorker\SymfonyMailerQueueWorker->processItem(Object) (Line: 107)
Drupal\queue_ui\QueueUIBatch->step('symfony_mailer_queue', Array) (Line: 297)
_batch_process() (Line: 139)
_batch_do() (Line: 95)
_batch_page(Object) (Line: 52)
Drupal\system\Controller\BatchController->batchPage(Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 709)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Drupal 11.1
Symfony Mailer 1.5.0

Enable module
Goto /admin/config/system/mailer/policy/_
Add Queue sending
Goto /user/password
Recover password

I use Queue UI 3.2.1
Goto /admin/config/system/queue-ui
Execute Sends emails and retries failures

Thank you

We had the same issue, specifically this error was being fired from the `user` EmailBuilder supplied by `symfony_mailer`.

Our solution was to apply the "Queue sending" only to policies from our custom modules and not on the global "*All*" policy.

We should be able to filter the unknown parameters from the mail like this:

        $reflection = new \ReflectionMethod($builder, 'createParams');
        $valid_params = array_intersect_key($params, array_flip(array_map(
          static fn($param) => $param->getName(),
          // Skip the first parameter, which is the email object itself.
          array_slice($reflection->getParameters(), 1)
        )));
        $builder->createParams($email, ...$valid_params);

I think this might best be fixed in Drupal\symfony_mailer\EmailFactory.

I applied the patch against the 1.1.0 release on Drupal 10, and all is working as it should be, FWIW.