Likely temporary server issues, since getDifference should
realistically not fail with flood waits. In any case,
stopping early until the problem is resolved is the correct
approach.
Closes#3916.
The new MessageBox system is not designed with "albums come in the
same updates container" in mind (in fact, there was a note about this).
This version was also not intended to be published to PyPi, but it is,
so a workaround must be made for events.Album to remain working.
In essence, AlbumHack will always be used even if it technically did not
need to be used previously. This will cause a small delay for those
updates, but it should not be a major issue.
If saving every minute or new entities fails, it's not fatal.
Other places are not checked because it is more critical for
information to be saved, such as disconnect, where we want to
crash if the session cannot be accessed.
See discussion on https://github.com/LonamiWebs/Telethon/commit/49713b2.
The problem with the automatic approach is that some scripts may do
some "fancier" things with the way they register updates, so it was
prone to failure (a handler could be added but since the last request
was without updates, nothing would be received).
This new approach is a bit more annoying to opt-into but also more
explicit.
It was added back in bfc408b probably due to a misunderstanding of
https://docs.python.org/3/howto/logging.html#configuring-logging-for-a-library.
The default behaviour of logging WARNING and above is good and
desirable (hiding unhandled exceptions in update handlers by default
was a big, accidental mistake). NullHandler is used to *prevent*
this good default, so it shouldn't be used in the first place.
This should mitigate "the code doesn't work but there are no errors"
situations. Users not wanting this behaviour can configure logging
with a high-enough level that won't print anything, or set a filter.
This behaviour is deprecated and will be removed in future versions
of Python. Technically, it could be considered a bug (invalid usage
causing different behaviour from the expected one), and in practice
it should not break much code (because .get_event_loop() would likely
be the same event loop anyway).
