I got a response from the Mailjet technical support:
"The 404s are occurring because you are attempting to interact with resources/objects that do not exist.
The 400s are seemingly exclusively being generated via POST calls to /v3/REST/contactmetadata, the 404s I saw were being made to /v3/REST/contactslist/Array/ManageContact, which is not a resource I am aware exists on Mailjet's side.
You can find all of the available resources together with examples here: https://dev.mailjet.com/email/reference/"
Anyone idea what is happening here or how to fix that?
After applying this patch to alpha2 I started getting these errors instead:
Warning: Array to string conversion in Mailjet\Client->buildURL() (line 251 of vendor/mailjet/mailjet-apiv3-php/src/Mailjet/Client.php) #0 web/core/includes/bootstrap.inc(347): _drupal_error_handler_real()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #1 [internal function]: _drupal_error_handler()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #2 vendor/mailjet/mailjet-apiv3-php/src/Mailjet/Client.php(251): join()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #3 vendor/mailjet/mailjet-apiv3-php/src/Mailjet/Client.php(117): Mailjet\Client->buildURL()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #4 vendor/mailjet/mailjet-apiv3-php/src/Mailjet/Client.php(169): Mailjet\Client->_call()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #5 web/modules/contrib/mailjet/src/MailjetHandler.php(245): Mailjet\Client->post()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #6 web/modules/contrib/mailjet/mailjet.module(465): Drupal\mailjet\MailjetHandler->syncMailjetContact()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #7 web/modules/contrib/mailjet/mailjet.module(404): mailjet_sync_single_user()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #8 [internal function]: mailjet_user_delete()
TypeError: htmlspecialchars(): Argument #1 ($string) must be of type string, array given in htmlspecialchars() (line 432 of web/core/lib/Drupal/Component/Utility/Html.php)
#0 web/core/lib/Drupal/Component/Utility/Html.php(432): htmlspecialchars()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #1 web/core/lib/Drupal/Component/Render/FormattableMarkup.php(270): Drupal\Component\Utility\Html::escape()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #2 web/core/lib/Drupal/Component/Render/FormattableMarkup.php(216): Drupal\Component\Render\FormattableMarkup::placeholderEscape()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #3 web/core/lib/Drupal/Core/StringTranslation/TranslatableMarkup.php(195): Drupal\Component\Render\FormattableMarkup::placeholderFormat()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #4 web/core/lib/Drupal/Component/Utility/ToStringTrait.php(15): Drupal\Core\StringTranslation\TranslatableMarkup->render()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #5 [internal function]: Drupal\Core\StringTranslation\TranslatableMarkup->__toString()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #6 web/core/lib/Drupal/Core/Logger/LogMessageParser.php(16): strpos()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #7 web/core/modules/syslog/src/Logger/SysLog.php(78): Drupal\Core\Logger\LogMessageParser->parseMessagePlaceholders()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #8 web/core/lib/Drupal/Core/Logger/LoggerChannel.php(127): Drupal\syslog\Logger\SysLog->log()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #9 vendor/psr/log/Psr/Log/LoggerTrait.php(99): Drupal\Core\Logger\LoggerChannel->log()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #10 web/modules/contrib/mailjet/mailjet.module(468): Drupal\Core\Logger\LoggerChannel->notice()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #11 web/modules/contrib/mailjet/mailjet.module(404): mailjet_sync_single_user()
Jul 20 12:19:07 ip-172-31-7-225 drupal: #12 [internal function]: mailjet_user_delete()So the question is, does this patch actually fix the issue or just return different values?
I get the error when trying to delete a user account and it obviously fail.
@damondt I would argue that's a hack, at least a workaround, not the same as encrypting the username field. Actually that is already what we do for security reasons, but like already said, it's not exactly the same thing, because login etc. gets more complicated.
I think you are right about the GDPR, but as a good guidance, any PII should be stored encrypted.
I would say that this is a high priority issue, because this module is the only one that supports encrypting field values in Drupal. Additionally there is no module that supports encrypting usernames.
Because "Username" is considered PII (personal identifiable information) and should be always kept encrypted. There are a lot of companies using Drupal that are under GDPR, HIPAA or storing information as a part of a medical device. Does this means Drupal is not a option for them, because there is no solution to encrypt the "Username"?
You can remove the batch items from the Queue directly from the database by:
delete from queue where name = 'field_encrypt_update_entity_encryption';
Just be sure the deed was done correctly, meaning the fields processed or set the batch to run again. I could not figure out why I got that error in the first place.