If my .py code for the Telegram bot hasn't been

running for 6 hours and during that time, 5000 messages have been sent to the bot, will my bot respond to all 5000 messages or just 100? 🤖🕒📊👀

If your code is not a total shit than to 5000, it will just take 50 requests to get all of them

How will it read 5000 entries if the limit of getUpdates is 100?

by passing different offsets?

How do you know how many messages came in if the bot was offline?

just count each one that you receive when you go online?

You just said that the limit is 100, how do you count all of them then (presumably, the actual message count of the messages outside the limit can be anything from 100 to e.g. 10000)? To my understanding you can’t get the exact count of messages straight away and if we would go the date route, then we would have to continue fetching getUpdates until we get to that exact “shut off” date, requiring us to loop through all of the messages, which doesn’t sound optimal

Straight away - yes. You are looping through updates all the time when bot is running using polling, why not do it again? You don't even need an extra loop for that

The bot was off, after it comes back from the hiatus it gets to read the last 100. So the queue would be backwards, as in the freshest messages get processed first and then the older ones?

Did you ever code your bot where you did not just let library do all the updates parsing part for you?

I coded the polling mechanism I had by myself to your surprise, there’s no need to get passive aggressive. I was just trying to understand your standpoint since the Telegram API is still new for me

so you say, in website of getupdate there will show 100 message, but when i use library like ptyhon-tleegram-bot, and run my code bot will response other message which is not in getupdat???

My messages looking aggressive is a problem for me that I can't really solve: I am not putting any hate in them, that's just the style I am writing. Sorry if that somehow... Touched you? Anyway, back to the point. I find it really weird that you don't understand how polling works. There's a limit you can get in a single request. And each update has an ID (not different for vk com/any polling Ive made by myself). If a program does not know the latest id, it will receive all the old updates before their amount hits the limit. Then it stores latest id and uses it in a new polling request. And the server is removing old updates from pending list (aka it is impossible to get same update twice if you already willed to get a newer one) and sending only newer ones

When I was developing my bot, I always had the messages stack up in the getUpdates request, the ones shown to me before I call the endpoint again didn’t ever go away

For instance you have update with id 1. Once you make new request with offset_id=2, telegram will not ever return update 1 again. Even if you set offset back to 0/1

So we can get the latest message ID and the offset ID saved in the DB, that way we can offset till that value, and if we would have message 5000 as the last one, when our bot came back to life getUpdates would show us the latest ID, let’s say 15000, so we can subtract and calculate the offset IDs as 1 per 100 messages?

I don't quite understand your plan. When your bot comes back to life, just set offset to an zero. As I said before, confirmed updates would not get listed anymore. That's how I always do it. Then you will receive 100 updates in a FIFO order. Remember the latest update id there and use (it+1) in next getupdates. Once you finish getting old ones and finally got into waiting, subtract latest known update id from one you have stored in db

Alright, thanks for bearing with me, I guess I have to experiment more :D (and get through the docs more carefully)

Goodluck :)

Did you read all messages I've sent to egor?

there was a lot of technical words very hard to understand the meaning

That way or another I have answered your question already: https://t.me/BotTalk/814369