-
Notifications
You must be signed in to change notification settings - Fork 0
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
Support TBA restarts/transient errors more gracefully #9
Comments
I am not convinced this is strictly necessary — the underlying urllib3.connectionpool.HTTPConnectionPool is explicitly marked as thread-safe, but lots of pieces along the way seem to have had questions documented online that don't seem to have definitive answers. I might want to sit down and dig through this all myself one day. But, for now, because of the ambiguity and because I am not entirely sure how reusing a connection pool in a situation with potentially more than 10 long-lived connections at a time (one `getUpdates` per bot) might affect things, I think this should gain some benefit without introducing any problems. I intend for a followup to introduce rate limiting and retries into ntelebot.requests._LOCAL.session (see #9). I also intend for ntelebot.requests to be more or less a drop-in replacement for the top-level requests module. (You should be able to replace "import requests" with "from ntelebot import requests" with no other code changes, though for now I'm explicitly changing "requests.*" references to "ntelebot.requests.*" to avoid ambiguity.) Release as 0.4.4.
My test bot's 6 a.m. announcement didn't come through until 6:10 today.
|
It looks like the production instance got the same error a single time during a poll a little earlier:
|
(I'm now taking a detour of possibly switching from requests to httpx, both to switch to HTTP/2 and possibly moving from thread-per-poll loop to asyncio. The former would probably be a drop-in replacement, but the latter would be a major rewrite/API change.) |
Despite what I recently suggested, TBA does go wonky every now and then, flooding the logs with both:
and:
mixed together. (I assume the latter causes rapid retries that trigger the former.)
To date, these only seem to have happened during
getUpdates
polls (which are designed to restart every 10 seconds no matter what), but I think I'd like to go ahead and retry at the ntelebot (versus metabot) level just in case this ever kills an actual mutation.I'm not sure if this should be done at the requests level (that applies rate limits to things like
api.weather.gov
too), or just tontelebot.bot._Request.__call__
.The text was updated successfully, but these errors were encountered: