Budgets Endpoint Timing Out on Every Call

[jcsacto]

• lunchable version: 1.3.1
• Python version: 3.8.18
• Operating System: Windows 11

Description

The budgets endpoint is timing out on every run, I get a 'The read operation timed out' response when trying to run the simple Python code below.

This call works fine on the LunchMoney native API (although it is historically slower than other calls).

What I Did

import pandas as pd
from lunchable import LunchMoney

lunch = LunchMoney(access_token="")

budgets = lunch.get_budgets(start_date='2024-02-01', end_date='2024-02-29')

print(budgets)

Paste the command(s) you ran and the output.
If there was a crash, please include the traceback here.

timeout Traceback (most recent call last)
File c:\Users\Jon Crosby.conda\envs\lunchmoneyEnv\lib\site-packages\httpcore_exceptions.py:10, in map_exceptions(map)
9 try:
---> 10 yield
11 except Exception as exc: # noqa: PIE786

File c:\Users\Jon Crosby.conda\envs\lunchmoneyEnv\lib\site-packages\httpcore_backends\sync.py:126, in SyncStream.read(self, max_bytes, timeout)
125 self._sock.settimeout(timeout)
--> 126 return self._sock.recv(max_bytes)

File c:\Users\Jon Crosby.conda\envs\lunchmoneyEnv\lib\ssl.py:1259, in SSLSocket.recv(self, buflen, flags)
1256 raise ValueError(
1257 "non-zero flags not allowed in calls to recv() on %s" %
1258 self.class)
-> 1259 return self.read(buflen)
1260 else:

File c:\Users\Jon Crosby.conda\envs\lunchmoneyEnv\lib\ssl.py:1134, in SSLSocket.read(self, len, buffer)
1133 else:
-> 1134 return self._sslobj.read(len)
1135 except SSLError as x:

timeout: The read operation timed out
...
81 raise
83 message = str(exc)
---> 84 raise mapped_exc(message) from exc

ReadTimeout: The read operation timed out

[juftin]

We can set four kinds of Timeout configuration on the underlying httpx.Client:

There are four different types of timeouts that may occur. These are connect, read, write, and pool timeouts.

• The connect timeout specifies the maximum amount of time to wait until a socket connection to the requested host is established. If HTTPX is unable to connect within this time frame, a ConnectTimeout exception is raised.
• The read timeout specifies the maximum duration to wait for a chunk of data to be received (for example, a chunk of the response body). If HTTPX is unable to receive data within this time frame, a ReadTimeout exception is raised.
• The write timeout specifies the maximum duration to wait for a chunk of data to be sent (for example, a chunk of the request body). If HTTPX is unable to send data within this time frame, a WriteTimeout exception is raised.
• The pool timeout specifies the maximum duration to wait for acquiring a connection from the connection pool. If HTTPX is unable to acquire a connection within this time frame, a PoolTimeout exception is raised. A related configuration here is the maximum number of allowable connections in the connection pool, which is configured by the limits argument.

I believe the default is 5 for all. Let me think on this and set some better defaults - I should have a fix soon. Any recommendations are welcome.

[jcsacto]

Thanks for the quick reply as always @juftin connectivity timeouts seem reasonable at 5 seconds (if it can't connect in that time than it's probably not going to), The read is the one this is probably getting stuck on, sometimes this call to Lunch Money API can take between 10 and 20 seconds, so bumping that to 30 seconds seems reasonble. I'm not using Lunchable to write anything but depending on how slow Lunch Money is that might be a 10 to 20 second event also. Hope that helps a bit.

[juftin]

Gotcha, I don't pay super close attention to the response times so thanks for the context, that's very helpful. Given that, I'm inclined to set the following timeout defaults, what do you think?

timeout = httpx.Timeout(connect=5, read=30, write=20, pool=5)

[jcsacto]

Sounds good to me, I can keep an eye on things and let you know how it works.

[juftin]

Just released the fix on 1.3.2 - let me know how it goes

[jcsacto]

looking good so far! A few new unexpected columns came thru but was able to clean up my downstream fine, the important part is there were no timeouts! Thanks so much!

[juftin]

looking good so far! A few new unexpected columns came thru but was able to clean up my downstream fine, the important part is there were no timeouts! Thanks so much!

New unexpected fields came through? Which ones?

[jcsacto]

archived, order and recurring columns were new (to me at least).

[juftin]

archived, order and recurring columns were new (to me at least).

Ah, me too. Those were documented last week: lunch-money/developers@ad87916

The docs have been getting updated a lot recently - I'll go through soon and see what I'm missing. I do like that these fields are flowing through the JSON into the lunchable objects now though - that's new. Until they're defined on the underlying models they don't get validated/coerced into the right data types by pydantic though.

[jcsacto]

sounds good, would be cool if lunchable can flatten the 'recurring' column nested json someday also. ;)