-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
request timeout exception? #49
Comments
@RettBehrens did this get handled in the core API? I am seeing 5 minute read timeouts on various endpoints, including earlier today. As an example We have a fairly large app on Xero's store (> 400 clients) and this is starting to cause some issues for us at uncat.com. |
@jaredthecoder I’m not at Xero anymore. Please contact [email protected] and they’ll direct your query to the appropriate point of contact. |
I have :( They are not helpful. I will tell them you pointed me there again. |
I did mention this by the way; whatever is going on here is leading to our refresh tokens to get overwritten and then lead to the classic reuse issue, which then expires a ton of clients. |
@rdemarco-xero are you able to take a look at this? This is plaguing a bunch of different devs I have talked to and API support is not able to help. |
Created based on conversation with community developer:
"Occasionally the Journals endpoint takes a long time to respond - last night 235seconds for 1 page of Journals. Yes, it's an anomaly as the same Org can be used and it doesn't exhibit the same issue.
So, looking at the Python library it appears http requests default to timeout=None, which reading https://docs.python-requests.org/en/master/user/advanced/#timeouts suggests the timeout will be infinite but can be overridden.
If that is the case, then it appears that there will be no timeout exception raised for all API calls to the Xero APIs. My recommendation to our integration partner, who has inbuilt their own timeouts (this is bad!!!) was that they utilise the HTTP request timeout and retry, but they appear to not be overriding the parameter!
If the exception is raised from a timeout it appears it will be returned to the calling function of the Xero API as only exceptions.HTTPStatusException are handled within the SDK so exceptions.Timeout will need to be caught."
The text was updated successfully, but these errors were encountered: