Improperly implemented interface \Drupal\Core\Mail\MailInterface

Created on 16 September 2022, over 2 years ago
Updated 24 February 2023, almost 2 years ago

Issue:
The interface method \Drupal\Core\Mail\MailInterface::mail does not throw any exceptions.
If there is an error, the implementation needs to log it and return "FALSE"

It's possible to have mail errors, and we don't want that causing WSODs.

Mainly this seems to be a problem with allowing exceptions from fastglass/sendgrid to percolate, when they should be caught and logged.

Steps to reproduce:
There are countless ways to send an email that fastglass/sendgrid considers invalid.

Proposed resolution:
* all calls to fastglass/sendgrid methods need to be wrapped with try/catch
* exceptions should be logged, rather than percolated
* return FALSE on error, rather than allowing the exception to be thrown up the chain

πŸ› Bug report
Status

Fixed

Version

2.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States AaronBauman Philadelphia

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States greggles Denver, Colorado, USA

    This solution seems reasonable to me. Thanks for identifying this problem and suggesting the solution.

  • First commit to issue fork.
  • Status changed to Needs work almost 2 years ago
  • πŸ‡ΊπŸ‡ΈUnited States rymcveigh

    I'm marking this as needing work and creating a new merge request because the current patch can not be applied to the 8.x-2.x branch.

  • @rymcveigh opened merge request.
  • πŸ‡ΊπŸ‡ΈUnited States rymcveigh

    I moved your changes into an MR and based it off of the 8.x-2.x branch so it should be mergeable. I'm confused why we need the extra catch with the log. It looks like most (if not all) of the exceptions are logged in the original ::mail() function. Is there an exception that isn't covered? If so, would it be better to adjust the original function rather than add a new function to the code base?

  • πŸ‡ΊπŸ‡ΈUnited States lkacenja

    I looked this over and presume that the reason for creating a "doMail" method was to facilitate easy wrapping of the rather lengthy business logic that was formerly in the "mail" method. We do want to make sure we catch all the SendgridExceptions raised in that code. Creating a new method prevents the "mail" method from taking up extra horizontal space, but I do see the virtue in not adding new methods willy-nilly. I think either creating a new function (as authored) or wrapping all the contents of the original mail method and not creating a new function are both fine.

    In my opinion, if a "doMail" method is added it should be protected. Otherwise, the intention of the original interface is violated.

  • Status changed to Needs review almost 2 years ago
  • πŸ‡ΊπŸ‡ΈUnited States rymcveigh

    I adjusted the doMail function to be protected in commit 10ca0226.

  • πŸ‡ΊπŸ‡ΈUnited States rymcveigh
  • Status changed to Fixed almost 2 years ago
  • πŸ‡ΊπŸ‡ΈUnited States Perignon

    PR merged.

    Thanks for the help and contribution

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024