Contrib.social

Mailchimp client does not respect the api_timeout anymore

Open on Drupal.org →
Created on 15 August 2023, over 1 year ago
Updated 14 September 2023, over 1 year ago

Problem/Motivation

From my observations in the recent releases the configured API timeout (api_timeout) is not respected anymore. Instead it falls back to the 10 second default limit from the Mailchimp library.

Steps to reproduce

It seems that the error was introduced in this commit https://git.drupalcode.org/project/mailchimp/-/commit/8054be598ee3f444c7... , when oAuth was added to the module.

The passed $http_options need to be added as a second parameter to the API class instead of the instance, because that supports the $http_options as a second constructor parameter.

Instead of this

return new $class($api_class, $http_options);

it should be like this a few lines before.

$api_class = new $api_class_name($authentication_settings, $http_options);

Additional thoughts
Because of #2768455: High cURL timeout can lead to Denial of Service → , when the api_timeout was initially introduced it's not recommended to set the timeout to a high value. Especially when you use a subscription block and the Mailchimp server responds slow (and Drupal cache is cleared).

Therefore it might be better, if could configure overwrite a custom timeout for different use-cases. For subscriptions blocks a short timeout is preferable, but when using extensive API calls like the ones described above, we like to set a higher one. Currently there is no possibility to do so, even on the mailchimp-api-php side, because the guzzle client is hidden behind a private property.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

🐛 Bug report
Status

Fixed

Version

2.0

Component

API

Created by

🇩🇪Germany szeidler Berlin

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

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024