`updateChatMessageTtl` is not implemented and resulted in exception thrown

[DamienLaw]

`updateChatMessageTtl` is not implemented and resulted in exception thrown

[ForNeVeR]

Any idea what exactly is this message? I cannot find it in td_api.tl from tdlib: https://github.com/tdlib/td/blob/master/td/generate/scheme/td_api.tl

[ForNeVeR]

In fact, it is only mentioned in an old changelog (from 1.8.0, 2021-12-29), and nowhere else.

Are you sure it exists? Under what circumstances do you receive that?

[DamienLaw]

When I was running the C# sample TdLib.Samples.GetChats.

I'm only getting error on one of my accounts. But not on the other.

[ForNeVeR]

Why do you think that's updateChatMessageTtl and not something else? Have you found that in debug mode?

[DamienLaw]

Yes, I was running the sample in debug mode when I was hit by the exception.

The @type indicated that it's updateChatMessageTtl (underlined at the lower left of the screenshot).

[ForNeVeR]

I would recommend opening an issue upstream.

There is no such type in the actual tdlib sources, and I don't understand how we should generate it.

[DamienLaw]

The reference is specified here and here.

Does it help?

[ForNeVeR]

These links look identical. And, unfortunately, no, it does not help.

There are still no any details about this class in the .tl specification. So, we cannot generate it. And it doesn't exist in tdlib sources.

[DamienLaw]

These links look identical.

Sorry, the 2nd link supposed to be td_api.h

Perhaps, that class has been removed from the API but the server is still sending it. Is it possible to ignore unrecognised API and logs them instead of throwing unhandled exceptions and killing the client?

[ForNeVeR]

Perhaps, that class has been removed from the API but the server is still sending it.

On this, I unfortunately have no idea. This is a question for upstream developers.

Is it possible to ignore unrecognised API and logs them instead of throwing unhandled exceptions and killing the client?

But we are doing that already. An ExceptionThrown event is emitted when there's an exception in the Receiver loop; there are no unhandled exceptions anywhere.

(Also, I found that the exception is not even exposed anywhere, I'll create an improvement request for that matter.)

Do you suggest some other behavior?

[DamienLaw]

You're right, there's no unhandled exception. I was only receiving that during debugging. It's not really an issue then. I'll proceed to close this issue. Thanks for your time looking into this.