Problem/Motivation
Since 3.1.4, mailchimp_cron() calls Processor::pingApi() on every cron run, even when queue processing is disabled. On sites with an invalid, missing or deactivated API key, the ping fails and logs an error on every cron run. The 60-second throttle in Processor::ping() doesn't help when cron runs every few minutes. On our multisite, 5 sites with bad keys produced about 145 errors each every 12 hours, starting right after we deployed 3.1.5.
These errors also made cron look broken after every deployment. Our cron wrapper treats any [error] in drush cron output as a failed run and skips the Dead Man's Snitch check-in. Drush only echoes Drupal log messages when the service container was built by a drush process. Our deployments end with drush commands, so after each deploy the ping errors show up in drush output. A cache clear hides the problem (a web request rebuilds the container without the drush logger), but the errors keep being logged. That makes this very hard to reproduce: it only appears on environments that are formally deployed to and monitored.
Also, ping() only catches MailchimpAPIException, but MailchimpGuzzleHttpClient only converts Guzzle's RequestException. In Guzzle 7, ConnectException (DNS failure, connection refused, connect timeout) doesn't extend RequestException, so a network failure would escape hook_cron(), even on sites with a valid key.
Steps to reproduce
- Install Mailchimp 3.1.5 with OAuth disabled and set an invalid API key, e.g.
drush cset mailchimp.settings api_key 'bad-key-us1'. - Run
drush cr, thendrush cronseveral times, more than 60 seconds apart. - Every run prints
[error] Mailchimp API ping failed: 401 ...and logs it to watchdog.
Proposed resolution
The connectivity check should fail quietly:
- Don't log an error on every cron run when the ping keeps failing, for example only when connectivity changes from OK to failing. The status report already shows the current ping state.
- Catch network-level exceptions in the ping so it can never abort
hook_cron(). - Consider skipping the ping when no API key or OAuth token is configured.
As a workaround, we uninstalled the module on the sites with invalid or missing keys.
Remaining tasks
- Maintainers to confirm the behavior and agree on how the ping should handle failures.
- Patch / merge request.
- Tests.
User interface changes
None.
API changes
None.
Data model changes
None.
Posted with assistance from Claude Opus 5.5 in VS Code.
Comments