auth_key_id mismatch after `logOut`

[keleftheriou]

I sometimes (but not always) see this type of error right after logging out. I’m not sure what it means or why it’s happening:

Session closed: [Error : 0 : Invalid mtproto message: auth_key_id mismatch [found = 0x0a0d3e6c6d84683c] [expected = 0xba91dcf84a3bff0a]] Session:1:main::Connect::HttpLongPoll::[123.123.123.123:443] to DcId{1} over HTTP

When the error occurs, my client never receives the final AuthorizationStateClosed update.

[levlam]

Are you using TDLib on watchOS?

[keleftheriou]

Yes, I am using it on watchOS.

[levlam]

What is probability of getting this error?

[keleftheriou]

About half the time. Is this somehow specific to watchOS?

[levlam]

The problem is in HTTP transport and it currently used by default only on watchOS.

[keleftheriou]

You mean instead of HTTPS? Is it possible to change the default transport used on watchOS?

I’m currently using TdJson. Is the C++ TdStatic version any different in this regard?

Otherwise, what is the preferred way to build a watchOS client?

[levlam]

No. On all other OS TCP transport is used by default. There is no access to raw sockets on watchOS, so it is forced to use HTTP transport.

[keleftheriou]

It appears this might have changed with watchOS 6, see here: https://github.com/socketio/socket.io-client-swift/issues/1215

From the watchOS 6 release notes:

URLSessionWebSocketTask and URLSessionStreamTask are now available for use in watchOS apps. (49779789)

Also URLSessionDataTask supports HTTPS.

Are any of these technically sufficient for a Telegram client on watchOS, if one was willing to spend the time to make the necessary changes?

[levlam]

HTTPS makes no difference. Telegram doesn't have HTTP/HTTPS API. HTTP is used only as a transport.

[keleftheriou]

Thanks.

Is any of URLSessionWebSocketTask / URLSessionStreamTask / URLSessionDataTask technically sufficient for a Telegram client on watchOS, if one was willing to spend the time to make the necessary changes?

I’m trying to determine if I should build an independent watchOS client or not.

[levlam]

TDLib already uses URLSessionDataTask. Existence of others makes no difference and is irrelevant to the issue.

[keleftheriou]

I see. Then what are the implications of TDLib using HTTP transport on watchOS?

Are there any security concerns or other downsides?

And is there anything I can do to prevent or handle the auth_key_id mismatch error?

[levlam]

There are no downsides, except it is suboptimal, but watchOS has no better alternatives anyway. The error can't be avoided and needs to be properly handled in TDLib.