Connection timed out
Before we start...
- [x] I've searched existing issues, but my problem hasn't been reported yet.
- [x] I've read the documentation (including notes on error messages and rate limiting), but my problem is something else.
- [x] I've tested the behaviour on Skype for Web, and it works there but not with SkPy.
Summary
Since march 10 I am getting connection timed out. It seems sk.user didn't get the token and kept requesting until hit the limit
Code sample
from skpy import Skype, SkypeChats
sk = Skype("******", "****") # connect to Skype
sk.user # you
#for contact in sk.contacts:
# print(contact.id)
Code output
File "/Users/sunny/Documents/Desktop-Projects/Scarlet-Sparrow/Python/Skype/skype.py", line 39, in <module>
sk = Skype("***", "***") # connect to Skype
File "/opt/homebrew/lib/python3.13/site-packages/skpy/main.py", line 69, in __init__
self.conn.getSkypeToken()
~~~~~~~~~~~~~~~~~~~~~~~^^
File "/opt/homebrew/lib/python3.13/site-packages/skpy/conn.py", line 197, in inner
return method(*args, **kwargs)
File "/opt/homebrew/lib/python3.13/site-packages/skpy/conn.py", line 438, in liveLogin
self.getRegToken()
~~~~~~~~~~~~~~~~^^
File "/opt/homebrew/lib/python3.13/site-packages/skpy/conn.py", line 520, in getRegToken
token, expiry, msgsHost, endpoint = SkypeRegistrationTokenProvider(self).auth(self.tokens["skype"])
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
File "/opt/homebrew/lib/python3.13/site-packages/skpy/conn.py", line 952, in auth
endpointResp = self.conn("POST", "{0}/users/ME/endpoints".format(msgsHost), codes=(200, 201, 404),
headers=headers, json={"endpointFeatures": "Agent"})
File "/opt/homebrew/lib/python3.13/site-packages/skpy/conn.py", line 239, in __call__
resp = self.sess.request(method, url, headers=headers, **kwargs)
File "/opt/homebrew/lib/python3.13/site-packages/requests/sessions.py", line 589, in request
resp = self.send(prep, **send_kwargs)
File "/opt/homebrew/lib/python3.13/site-packages/requests/sessions.py", line 703, in send
r = adapter.send(request, **kwargs)
File "/opt/homebrew/lib/python3.13/site-packages/requests/adapters.py", line 688, in send
raise ConnectTimeout(e, request=request)
requests.exceptions.ConnectTimeout: HTTPSConnectionPool(host='client-s.gateway.messenger.live.com', port=443): Max retries exceeded with url: /v1/users/ME/endpoints (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x1048e3750>, 'Connection to client-s.gateway.messenger.live.com timed out. (connect timeout=None)'))
Explain your code
Simple test code
SkPy version
Latest
Python version
3.10
Anything else?
No response
Based on a note in https://github.com/Terrance/SkPy/discussions/290#discussioncomment-12414504 and a quick review of Skype for Web's activity, changes seem to be:
- messaging host is now
msgapi.teams.live.com(likely as part of the incoming Teams migration) - endpoints are no longer configurable
- authentication has changed (now uses an
Authenticationheader and requires client info)
I've pushed a minimal fix to branch teams-migration, which seems to be enough to list chats and messages on my account, so please report any further problems with that fix applied.
You can install it via the repo with pip install git+https://github.com/Terrance/SkPy@teams-migration.
I confirm with this sending chat message to a contact or a group/thread is also working.
I will report if anything happens before we migrated to teams.
Thanks.
Thanks for the update. However, when trying to send more than 3 messages in a row i get an error message:
raise SkypeRateLimitException("Rate limit exceeded", resp)
skpy.core.SkypeRateLimitException: ('Rate limit exceeded', <Response [429]>)
Code sample which was working fine recently:
for chat_id in chats:
ch = sk.chats.chat(chat_id)
ch.sendMsg("test")
If they've tightened the rate limits as part of this migration then there's little we can do about it.
Do you get similarly limited using Skype for Web?
In Skype for Web I can send how many messages I want without any rate limit.
Try again with the latest commit. If you're still being unreasonably limited, take a look at the headers and body of the failing request in SkPy (with SKPY_DEBUG_HTTP=1) vs. what Skype for Web is doing.
It helped to increase the number of messages to 7 before getting rate limited.
It seems like the limit is 6-7 requests per minute. That's what I can see with SKPY_DEBUG_HTTP=1 as well.
Thanks a lot for your help.
If (part of) the fix is to change the server to a Teams one, does that mean this can be adapted for Teams in the future (eg a TmPy)?
I encountered an issue during initialization.
After running:
pip install git+https://github.com/Terrance/SkPy@teams-migration
I received the following error:
File "/usr/local/lib/python3.9/site-packages/skpy/conn.py", line 267, in __call__: [SkypeApiException]
('501 response from POST https://msgapi.teams.live.com/v1/users/ME/endpoints/SELF/subscriptions', <Response [501]>)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[20250314 05:52:15 ERROR ] Full traceback:
File "/app/skypebot.py", line 555, in main
sp.loop()
File "/usr/local/lib/python3.9/site-packages/skpy/main.py", line 213, in loop
self.cycle()
File "/usr/local/lib/python3.9/site-packages/skpy/main.py", line 198, in cycle
events = self.getEvents()
File "/usr/local/lib/python3.9/site-packages/skpy/conn.py", line 79, in wrapper
return fn(self, *args, **kwargs)
File "/usr/local/lib/python3.9/site-packages/skpy/conn.py", line 79, in wrapper
return fn(self, *args, **kwargs)
File "/usr/local/lib/python3.9/site-packages/skpy/main.py", line 111, in getEvents
for json in self.conn.endpoints["self"].getEvents():
File "/usr/local/lib/python3.9/site-packages/skpy/conn.py", line 1173, in getEvents
self.subscribe()
File "/usr/local/lib/python3.9/site-packages/skpy/conn.py", line 1136, in subscribe
self.conn("POST", "{0}/users/ME/endpoints/{1}/subscriptions".format(self.conn.msgsHost, self.id),
File "/usr/local/lib/python3.9/site-packages/skpy/conn.py", line 267, in __call__
raise SkypeApiException("{0} response from {1} {2}".format(resp.status_code, method, url), resp)
Could you please help me troubleshoot this? Thank you!
I encountered the exact same error as described above.
Has anyone found a solution or workaround for this?
From watching Skype for Web, it doesn't look like it listens for events any more?
If you receive a message while a different chat is selected, the message doesn't come through. After a while (e.g. if you leave the tab in the background and later return to it), the client refreshes the conversation list, notices the chat has been updated, then fetches its messages again to get the new one.
This probably means the long-polling call we use for listening to events doesn't exist in the Teams-backed API (this also lines up with the 501 error, which corresponds to HTTP 501 Not Implemented), so skpy.SkypeEventLoop won't work any more unless someone else can spot a suitable replacement.
You can do something similar to Skype for Web and manually poll for updates via SkypeChats.recent() (which tells you which chats to fetch messages from) and SkypeChat.getMsgs() -- both of these should return a list of their respective objects (updated chats or unseen messages) since the last call, or an empty list if nothing's changed in the meantime.
@Terrance also I get skpy.core.SkypeRateLimitException: ('Rate limit exceeded', <Response [429]>) on this place
https://github.com/Terrance/SkPy/blob/5f75b96be1b213feafefe7ac6127a8c75318b993/skpy/chat.py#L497
It happens when I try to do self.chats.recent(). So, it starts successfully, as I see from your SKPY_DEBUG_HTTP=1 debugging mode. But after some requests it fails with
{"errorCode":429,"message":"API calls quota exceeded!","standardizedError":{"errorCode":429,"errorSubCode":1,"errorDescription":"API calls quota exceeded!"}}{"errorCode":429,"message":"API calls quota exceeded!","standardizedError":{"errorCode":429,"errorSubCode":1,"errorDescription":"API calls quota exceeded!"}}
So, looks like that I have too much conversations to get all chats objects to a list. And I can't set limits of requests, because it is part of your lib (just after fork). Do you have any ideas of way out?
Hi @khurshid-alam,
The ConnectTimeout error you're experiencing, along with several others in this thread, point to instability and rate limiting issues introduced by the backend changes to Teams. SkPy was originally designed for the older Skype architecture, and these changes are causing compatibility problems.
Your code snippet itself looks correct for basic SkPy usage, so the problem isn't in your implementation:
from skpy import Skype, SkypeChats
sk = Skype("******", "****") # connect to Skype
sk.user # you
The traceback clearly indicates the timeout occurs during the token retrieval process, well before your code attempts anything substantive. This, along with the other reports of 429 (Rate Limit Exceeded) and 501 (Not Implemented) errors across different SkPy features, suggests the library is struggling to interact reliably with the new Teams-based backend.
As mentioned in other comments, the SkypeEventLoop functionality based on long polling seems to be broken due to the backend not supporting it anymore. The suggested workaround of using SkypeChats.recent() and SkypeChat.getMsgs() to manually poll for changes is currently the most viable approach.
Regarding the rate limiting encountered even with recent(), like @mihalt reported, this is a significant constraint. Since SkPy fetches all recent chats at once, a large number of conversations can easily trigger rate limits. A possible improvement could be to implement pagination or batching within recent() to fetch chats in smaller chunks, reducing the likelihood of hitting these limits. This would involve modifying SkPy itself. Alternatively, if you know the IDs of the chats you're interested in beforehand, directly accessing them via sk.chats.chat(chat_id) bypasses the recent() call and might be less prone to triggering the limits.
Unfortunately, there's no quick fix within SkPy for these issues at the moment due to how deeply the underlying API changes affect its core functionality. Manual polling and targeted chat retrieval offer workarounds, while longer-term solutions would require significant refactoring of SkPy to accommodate the new API's behavior.
Things to try:
- add a
pageSizeparameter to the recent call, small enough to avoid limiting from one batch of chats (not sure if this endpoint accepts it or not) - comment out the group chat lookup, which will skip filling in most fields (admins, members, etc.) but should be sufficient for reading messages and only incur one API request when fetching recent chats
From watching Skype for Web, it doesn't look like it listens for events any more?
If you receive a message while a different chat is selected, the message doesn't come through. After a while (e.g. if you leave the tab in the background and later return to it), the client refreshes the conversation list, notices the chat has been updated, then fetches its messages again to get the new one.
This probably means the long-polling call we use for listening to events doesn't exist in the Teams-backed API (this also lines up with the 501 error, which corresponds to HTTP 501 Not Implemented), so
skpy.SkypeEventLoopwon't work any more unless someone else can spot a suitable replacement.You can do something similar to Skype for Web and manually poll for updates via
SkypeChats.recent()(which tells you which chats to fetch messages from) andSkypeChat.getMsgs()-- both of these should return a list of their respective objects (updated chats or unseen messages) since the last call, or an empty list if nothing's changed in the meantime.
What do you think about re-writing the loop to pull recent chats and iterate through them as if it was an event like how the loop worked with the proper rate limiting. Would this be difficult? I may give it a try, but my code is nowhere near production grade.
As a reminder, this library is not production-grade.
The current implementation of sync-state URLs (so that when you call e.g. getMsgs() a second time, it gives you the next batch) is global, so using this for the event loop will interfere with the ability to call these methods in user code. It probably needs some work to decouple that or otherwise make those safe to call, as well as some careful handling of past messages being pulled through next pages in the absence of new messages.
Pull requests welcome for an alternate event loop implementation.