AUTH_KEY_DUPLICATED after running for a while

[vladrmnv]

I'm trying to periodically rotate a few Gramjs clients. If I create a client and call destroy immediately after completing a request, after a few cycles I start to get AUTH_KEY_DUPLICATED errors.

This would be a pseudocode example:

while (true) {
  for (const stringSession of sessions) {
    const session = new StringSession(stringSession);
    const client = new TelegramClient(session);
    await client.connect();
    await client.getMe();
    await client.destroy();
    await sleep('5 seconds');
  }
}

This code will start producing AUTH_KEY_DUPLICATED errors after a few loops

[fastndead]

Have you tried disconnect instead of destroy?

[vladrmnv]

@fastndead yes. destroy calls disconnect internally + I want to dispose of the client, instead of setting it on a standby as disconnect does

[fastndead]

okay, got it! Well, I can only say that in my case i caught 406 because two instances of my application were connected at the same time with the same SESSION_STRING but via different TCP connections.
I know there's a problem with TIMEOUT errors on .disconnect in this library (#302).
Could it be that the instance of your client does not actually close TCP connection on .destroy?

One solution I can think of is issuing a separate fresh single-use SESSION_STRINGs for each client start.

Sort of like having one SESSION_STRING that will be an issuer session, and via this session you can receive OTP codes and issue different session strings for each connect. This obviously introduces overhead, but in theory it eliminates possibility of 406 AUTH_KEY_DUPLICATED error completely

[vladrmnv]

@fastndead I made sure that there are no 2 instances of the same client running at the same time. That would make sense.

Logging in for every new client instance might be a good fallback, but without knowing the original root cause I wouldn't trust to get my original sessions not to get duplicated as well.

Unfortunately there are more breaking issues with this library:

1. When there is a proxy error it does not propagate up the call stack. It would be printed to the logger, but never thrown to the parent caller. The process hangs indefinitely. Ok this can be fixed with running each gramjs client in a separate thread and killing the thread when it takes too long.
2. When fetching some entities I get Could not find a matching Constructor ID for the TLObject.... AFAIK these errors are thrown when an unsupported entity is encountered