Hi. Thanks for your PR. I guess you mean "potentially fixing #3893" rather than #3397?
However, what your PR does is "treat the symptoms", but unfortunately it does not really solve the issue that surfaced in #3893. I'm very hesitant with this approach, tbh. A try-except at that place in addition to a proper fixe for #3893 would be indeed desirable, but adding it without an actual fix (or propared infrastructure for a fix) does not seem a good solution to me.
In any case, I strongly suggest to make the logging level WARNING instead of DEBUG, as there is indeed something happening that the user should be aware of.

I agree.
My need to submit this PR comes from the same issue as #3397 and seems totally realted to #3893.

What's happening along these lines of code is that the callback is called with a timeout=0. I don't know exactly why, but in combination with these semi-random conditions (as explained in #3893) the get_updates() tends to throw the TimedOut exception. Then as it's not handled the application hangs and cannot stop properly.

My suggestion is to:

1. Put a bigger timeout value. I have tested and it also fixes the issue in the sense that it doesn't throw the TimedOut exception.
2. Also maintain the exception handling to avoid the application to hang there.

1. Put a bigger timeout value. I have tested and it also fixes the issue in the sense that it doesn't throw the TimedOut exception.

That is (very roughly) the idea outlined in #3893, yes. Although it's the read_timeout argument that needs to be adapted and not the timeout argument. Setting the timeout argument to a higher value would be false in this place, as we don't do long polling here.

2. Also maintain the exception handling to avoid the application to hang there.

As I said above, the additional exception handling does sound like a good idea to be, but I'm not comfortable with putting into place without adressing 1 first.

Please also note that a workaround is mentioned in #3893 (comment)

Closing in favor of #3963