You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our session can be taken out because of this error (failed workflow)
An exception to this is the AUTH_KEY_DUPLICATED error, which is only emitted if any of the non-media DC detects that an authorized session is sending requests in parallel from two separate TCP connections, from the same or different IP addresses.
Note that parallel connections are still allowed and actually recommended for media DCs.
Also note that by session we mean a logged-in session identified by an authorization constructor, fetchable using account.getAuthorizations, not an MTProto session.
Critically:
If the client receives an AUTH_KEY_DUPLICATED error, the session was already invalidated by the server and the user must generate a new auth key and login again.
So based on our current login flow this requires manual handling where a team member who has the access to do it:
logs in and removes all sessions from the TG client
runs yarn sms-auth.
that's it. I'll add handling in an open PR to remove any existing session strings from the DB when pushing a new one.
Automating this is really difficult because it's 2FA with a TG client with a code. Not certain how we'd implement this.
The text was updated successfully, but these errors were encountered:
I opened this two days ago and that is when I reset my session because of this error. So two days without using the connection and I've just received the error again when running the MTProtoAPI.
This may be resolved if we keep our connection warm.
Basically the data centers switch and sessions are tied to a particular one from what I gather. I'm unsure rn if we are being 'logged out for inactivity' or if the data centers are rotating and we need to handle that switch (there is quite a bit of info in the docs regarding this area of things, something along the lines of keeping keys for each but I wasn't sure that was applicable to our use-case)
Ideally it's one as it's a simple solve but requires more info
It doesn't make sense to me that the client is being logged out this frequently. I use Telegram on my devices and remain logged in, so their system is designed to allow for persistent login.
Our session can be taken out because of this error (failed workflow)
Critically:
So based on our current login flow this requires manual handling where a team member who has the access to do it:
yarn sms-auth
.Automating this is really difficult because it's 2FA with a TG client with a code. Not certain how we'd implement this.
The text was updated successfully, but these errors were encountered: