-
Notifications
You must be signed in to change notification settings - Fork 136
Incoming "updates" messages stop after first outbound API call #53
Comments
I suspect what is happening (though at present I have no firm evidence) is that each new API call outbound is somehow establishing a new session. Using the stable branch there's no terminal output, but on the unstable one, it prints In any case, this appears to collide with Telegram's documentation on how to handle updates, as per https://core.telegram.org/api/updates:
|
This theory does seem to be correct, in that if I schedule a call to |
Hm. Well, in theory that technique might have legs, but in practice I don't think I can make it work. I've been able to find little real concrete documentation about how the Only non-"short" updates have a All updates, even "short" ones, do seem to bump the The reason here is that the So, uhm... I basically have no idea :) I'm also finding it impossible to dig out any better documentation, either from Telegram themselves, or any third party, on how the whole seq + pts mechanism is supposed to be used. |
Oh, and in addition: if I did detect a hole in the flow of updates by comparing sequence numbers, I'd have to call |
OK after much further experimentation on actual observed values I come to a more accurate observation. Every Channel-type peer maintains its own pts sequence numbering, but the pts numbering of all the Chats and User dialogs all share the same counter, and it is that counter which the toplevel I could poll the |
Have you tried |
It's entirely unrelated. What that does is lists all of the current "dialogs" the user has - in particular that's all the users and chats, not the channels. So in fact it's the opposite of what I want. There is a call |
@leonerd But first I must fix message handling which was broken here But it's great that you noticed the pattern - that updates disappear after the first outgoing event. I have been long looking for ways to resolve this issue without the previous recursive function leading to the large message flood |
It surely just requires the client not to establish a new session for absolutely every outbound API call. The old code I had, based on |
Signed-off-by: Dmitry Boldyrev <ribkatt@gmail.com>
Just to note, PTS means persistent time stamp ;) |
Then what is qts mean? |
@zii its the same like pts for secret chats (in this case it means queue)... |
I have some proof-of-concept client code which is able to send or receive messages from Telegram. When I start it up, it performs the
updates.getState
call which enables the receipt of "updates" messages, and my client processes those to handle incoming messages. But the first time I make an outbound API call, perhaps to send a message, the incoming updates stop working.Tested with both the current stable build + my one-line "emit" patch (cf17f2b) and with the upstream "development" branch as installed by
npm install telegram-mtproto@3.0.5-unstable
.The text was updated successfully, but these errors were encountered: