Unable to communicate to Mollie: : HTTPSConnectionPool(host='api.mollie.com', port=443): Max retries exceeded with url: /v2/payments/xxxxxx

[hcvdwerf]

In azure I am running a simple mollie api and I got the following error:

mollie.api.error.RequestError: Unable to communicate with Mollie: HTTPSConnectionPool(host='api.mollie.com', port=443): Max retries exceeded with url: /v2/payments/xxxx. (Caused by ReadTimeoutError("HTTPSConnectionPool(host='api.mollie.com', port=443): Read timed out. (read timeout=10)"))

The fist attempt nearly always fail. Second succeed. What happens here? See code snippet bellow:

` unique_id = str(ObjectId())

    payment = mollie_client.payments.create({
        'amount': {
            'currency': 'EUR',
            'value': f'{total_price:.2f}'
        },
        'description': description,
        'redirectUrl': redirectUrl + '?id=' + unique_id,
        'webhookUrl': webhook_url,
        "metadata": {"uniqueId": unique_id}
    })`

[fjbender]

That's odd. I'm a bit of a noob on both Azure and Python, but is there a way for you to confirm which stage exactly times out? I'm getting some DNS vibes, as we have a discussion around mysterious DNS problems in mollie/mollie-api-php#578 spanning multiple years now.

Read timeout kinda reads like it's all resolved and connection was established, though.

[hcvdwerf]

That's odd. I'm a bit of a noob on both Azure and Python, but is there a way for you to confirm which stage exactly times out? I'm getting some DNS vibes, as we have a discussion around mysterious DNS problems in mollie/mollie-api-php#578 spanning multiple years now.

Read timeout kinda reads like it's all resolved and connection was established, though.

Which stage you mean? Thanks for your reply!

[fjbender]

Ah, sorry for being unclear. Do you have any way of identifying which step exactly fails, specifically whether it's the DNS lookup. The error message doesn't sound like it, but I want to be sure.

[geertjanvdenbosch]

Just to make sure that it's not a problem with Azure, could you verify that this only happens when sending a request to Mollie by sending a request to a different API? For quickly testing this, you could use https://httpbin.org/post to mimic a POST request.

[whyscream]

@hcvdwerf Any progress? The ReadTimeoutError means that you sent a request which was acknowledged by a server, but no response is coming back from that server. This is way past the DNS stage, so no issues there.
Maybe Azure has some kind of weird outbound proxy setup that interferes?

[sommejan]

@fjbender We have the same issue since we upgraded from 2.12.0 to 3.6.0. Sometimes we get the said error when receiving a mollie webhook and the error happens exactly when we are try to fetch the related payment with client.payments.get(payment_id). We cannot find any similarities between the requests involved and it also happens at different times but not each time but each time at the same point I mentioned above. Our Python version was upgraded from 3.7 to 3.10.

RequestError: Unable to communicate with Mollie: HTTPSConnectionPool(host='api.mollie.com', port=443): Max retries exceeded with url: /v2/payments/tr_xxx (Caused by ReadTimeoutError("HTTPSConnectionPool(host='api.mollie.com', port=443): Read timed out. (read timeout=5)"))
  File "xyy", line 512, in fetch_payment
    return client.payments.get(payment_id)
  File "mollie/api/resources/payments.py", line 44, in get
    return super().get(resource_id, **params)
  File "mollie/api/resources/base.py", line 97, in get
    result = self.perform_api_call(self.REST_READ, path, params=params)
  File "mollie/api/resources/base.py", line 42, in perform_api_call
    resp = self.client.perform_http_call(http_method, path, data, params, idempotency_key)
  File "mollie/api/client.py", line 276, in perform_http_call
    return self._perform_http_call_apikey(
  File "mollie/api/client.py", line 227, in _perform_http_call_apikey
    raise RequestError(f"Unable to communicate with Mollie: {err}")

[whyscream]

@sommejan @hcvdwerf Did you try the suggestion that @geertjanvdenbosch gave? What is the outcome when you run a script like the one below, in a similar environment as where you would create the payment at Mollie?

import logging
import time

import requests

logging.basicConfig(
    level=logging.DEBUG,
    format="%(asctime)s %(levelname)s %(name)s %(message)s",
)

start = time.monotonic()
resp = requests.post("https://httpbin.org/post", json={"foo": "bar"})
end = time.monotonic()

logging.info(f"HTTP response {resp} received after {end - start} seconds")
logging.info(f"HTTP response payload: {resp.json()}") 

Note that in the v3 client, a client timeout and retry mechanism was added. This should not interfere with a request to the Mollie API under normal conditions, but can be tuned if needed.

[sommejan]

@whyscream Yes, we don't have issues with other APIs. The script you provided got me a response received in 0.5265... seconds

[ErikNL81]

We have the exact same problem... When trying the call 10 times it might give the timeout 7 out of 10 and 3 times without a problem. Python 3.10.12 and mollie-api-python version 3.6.0.. We have so far been unable to pinpoint what the trigger might be for the timeout.

@whyscream when trying the above mentioned code we also instantly get a successful response.

Below our error code (tr_ was replaced with xxx)
mollie.api.error.RequestError: Unable to communicate with Mollie: HTTPSConnectionPool(host='api.mollie.com', port=443): Max retries exceeded with url: /v2/payments?from=tr_xxxxxxxx&limit=50 (Caused by ReadTimeoutError("HTTPSConnectionPool(host='api.mollie.com', port=443): Read timed out. (read timeout=10)"))

[geertjanvdenbosch]

Hi @ErikNL81, @sommejan and @hcvdwerf,

We're investigating the issue and we'll let you know when we know more what's causing this behaviour and possible fixes.

[compunity-fk]

Hi,

any updates on this issue? We are facing the same problem (mollie-api-python 3.6.0 and Python 3.12). Could not identify anything that causes that error on our side so far.

Thanks in advance!

[hcvdwerf]

Still relevant this issue

I have the following packages installed (python 3.9)

[tool.poetry.dependencies] python = "^3.9" flask = "^3.0.2" mollie-api-python = "3.7.2" pymongo = "^4.5.0" flask-cors = "^5.0.0" bcrypt = "^4.0.1" pyjwt = "^2.8.0" python-dotenv = "^1.0.1" azure-communication-email = "^1.0.0"

[geertjanvdenbosch]

Hi @hcvdwerf,

It's related to the way Azure handles timeouts https://learn.microsoft.com/en-us/azure/firewall/firewall-faq#how-does-azure-firewall-handle-idle-timeouts.

Could you try instantiating a new client each request?

[hcvdwerf]

Hi @hcvdwerf,

It's related to the way Azure handles timeouts https://learn.microsoft.com/en-us/azure/firewall/firewall-faq#how-does-azure-firewall-handle-idle-timeouts.

Could you try instantiating a new client each request?

I' am not using Azure firewall, VNET and an Azure VM. App is just deployed on Azure web app

[geertjanvdenbosch]

Hi @hcvdwerf,
It's related to the way Azure handles timeouts https://learn.microsoft.com/en-us/azure/firewall/firewall-faq#how-does-azure-firewall-handle-idle-timeouts.
Could you try instantiating a new client each request?

I' am not using Azure firewall, VNET and an Azure VM. App is just deployed on Azure web app

Could you still try instantiating a new client for each request? It resolved the issue for multiple other users who where hosing on Azure.

[hcvdwerf]

Hi @hcvdwerf,
It's related to the way Azure handles timeouts https://learn.microsoft.com/en-us/azure/firewall/firewall-faq#how-does-azure-firewall-handle-idle-timeouts.
Could you try instantiating a new client each request?

I' am not using Azure firewall, VNET and an Azure VM. App is just deployed on Azure web app

Could you still try instantiating a new client for each request? It resolved the issue for multiple other users who where hosing on Azure.

You mean imitate every time the following lines of code for each request:

mollie_client = Client(timeout=(2, 20)) mollie_client.set_api_key(MOLLIE_API_KEY)

That means no connection reuse

Correct?

[geertjanvdenbosch]

Hi @hcvdwerf,

Yes that's correct, no connection reuse (unless it's a call immediately following the previous one).