Exception thrown when unblocking a user via drush

The one-line error is not enough go go on. We need more of a stack trace to take this on as a bug report.

Patch attached to resolve this issue

We still need steps to reproduce to understand why the "to" field is empty.

Steps to reproduce:
- Fresh install of Drupal 9.5.9
- Create a new user without an email address (yes, Drupal does let you do this !)
- block the user via drush ('drush user:block

- unblock the user via drush ('drush user:unblock ')

At this point the following TypeError is thrown:

TypeError: Drupal\Core\Mail\Plugin\Mail\PhpMail::doMail(): Argument #1 ($to) must be of type string, null given, called in /app/web/core/lib/Drupal/Core/Mail/Plugin/Mail/PhpMail.php on line 118 in /app/web/core/lib/Drupal/Core/Mail/Plugin/Mail/PhpMail.php on line 162 #0 /app/web/core/lib/Drupal/Core/Mail/Plugin/Mail/PhpMail.php(118): Drupal\Core\Mail\Plugin\Mail\PhpMail->doMail(NULL, 'Account details...', 'test4,\n\nYour ac...', 'MIME-Version: 1...', '-fadmin@example...')
#1 /app/web/core/lib/Drupal/Core/Mail/MailManager.php(307): Drupal\Core\Mail\Plugin\Mail\PhpMail->mail(Array)
#2 /app/web/core/lib/Drupal/Core/Mail/MailManager.php(180): Drupal\Core\Mail\MailManager->doMail('user', 'status_activate...', NULL, 'en', Array, 'admin@example.c...', true)
#3 /app/web/core/lib/Drupal/Core/Render/Renderer.php(580): Drupal\Core\Mail\MailManager->Drupal\Core\Mail\{closure}()
#4 /app/web/core/lib/Drupal/Core/Mail/MailManager.php(181): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#5 /app/web/core/modules/user/user.module(1069): Drupal\Core\Mail\MailManager->mail('user', 'status_activate...', NULL, 'en', Array, 'admin@example.c...')
#6 /app/web/core/modules/user/src/Entity/User.php(139): _user_mail_notify('status_activate...', Object(Drupal\user\Entity\User))
#7 /app/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(597): Drupal\user\Entity\User->postSave(Object(Drupal\user\UserStorage), true)
#8 /app/web/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php(781): Drupal\Core\Entity\EntityStorageBase->doPostSave(Object(Drupal\user\Entity\User), true)
#9 /app/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(523): Drupal\Core\Entity\ContentEntityStorageBase->doPostSave(Object(Drupal\user\Entity\User), true)
#10 /app/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(804): Drupal\Core\Entity\EntityStorageBase->save(Object(Drupal\user\Entity\User))
#11 /app/web/core/lib/Drupal/Core/Entity/EntityBase.php(339): Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object(Drupal\user\Entity\User))
#12 /app/vendor/drush/drush/src/Drupal/Commands/core/UserCommands.php(159): Drupal\Core\Entity\EntityBase->save()
#13 [internal function]: Drush\Drupal\Commands\core\UserCommands->unblock('test4', Array)
#14 /app/vendor/consolidation/annotated-command/src/CommandProcessor.php(257): call_user_func_array(Array, Array)
#15 /app/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#16 /app/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#17 /app/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(390): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#18 /app/vendor/symfony/console/Command/Command.php(255): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#19 /app/vendor/symfony/console/Application.php(1039): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#20 /app/vendor/symfony/console/Application.php(275): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#21 /app/vendor/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#22 /app/vendor/drush/drush/src/Runtime/Runtime.php(124): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#23 /app/vendor/drush/drush/src/Runtime/Runtime.php(51): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#24 /app/vendor/drush/drush/drush.php(77): Drush\Runtime\Runtime->run(Array)
#25 /app/vendor/drush/drush/drush(4): require('/app/vendor/dru...')
#26 /app/vendor/bin/drush(120): include('/app/vendor/dru...')
#27 {main}

Understood. That information would be better placed in the issue summary.

What kind of email is Drupal sending in these cases? Is there really no “to” value? What even attempt sending the email?

I have put those 'steps to reproduce' in the issue summary as suggested.

In this case no email is sent from Drupal, but an attempt is made to send one. I notice that when you create a user without an email address through the admin screens, Drupal is clever enough to not attempt sending the email even if you click 'notify user' and tells you so. Perhaps the best solution would be to not even attempt to send the email when unblocking the user via drush as well ?

I attach a new patch to fix this issue at the PHP mail level as there was a problem with the first one.

I agree this should be fixed in drupal, not in drush, but I don't think the fix in #8 is the right one, this is too late in the chain. The mail should not be attempted to be sent instead of sending it to an empty string.

Yes that's what I thought too, the fix in #8 🐛 Exception thrown when unblocking a user via drush Needs work is a temporary one just to stop the exception - I'll work on a better fix further up in the logic

Here is a better patch that doesn't try to send the notification email if the user doesn't have an email address

Did not test

Sending to NW for the tests.

I think may be related - https://www.drupal.org/project/smtp/issues/3224734 →