Plenty of unnecessary exceptions were being raised and caught when
the input parameters were already correct. Furthermore, since
8abc7ade22, the in-disk cache was no
longer being used (so using usernames always reached out to memory).
Previously it would take the first chat it found and use the IDs
of all messages, even if they belonged to different chats, resulting
in unexpected messages to be forwarded.
Another solution would be to check that all the chats are the same,
but this solves the issue more nicely and makes it more powerful.
It's the only way to properly clean all background tasks,
which the library makes heavy use for in MTProto/Connection
send and receive loops.
Some parts of the code even relied on the fact that it was
asynchronous (it used to return a future so you could await
it and not be breaking).
It's automatically syncified to reduce the damage of being
a breaking change.
Destructors are not guaranteed to run. Despite having good
intentions (saving entities even if the user forgets), it
should be the user's responsability to cleanly close the
client under any circumstances.
This would cause issues in _cache_media since utils.is_image fails
in the second pass (it respects the stream's position, and the user
may rightfully pass a stream that should be read only from one pos).
We rely on >= 0 for setting the batch size to use (which must
be valid), so it makes sense to make negative limits equal 0.
This is similar to how asyncio.sleep(negative) sleeps 0 seconds,
despite the fact that time.sleep(negative) fails.
This should make it easier to maintain these methods, increase
reusability, and get rid of the async_generator dependency.
In the future, people could use this to more easily deal with
raw API themselves.
This one in particular may happen when iterating over messages,
perhaps more likely to happen if the group was created in a
different data center.
A small sleep of a few seconds also greatly increases the
chances of the error going away.
It was actually using FileLocation, which had the invalid expected
type for what was being returned. Instead it should have been this
other type.
In addition, more parameters are passed so that the method can have
all the information it needs to correctly cast the type.
Excepting ValueError when creating the SQLiteSession could hide
other errors (e.g. using a newer session file on an older version
of the library). Instead, the original error is raised, as if
sqlite3 was being imported within its __init__ method.
Letting _get_extension work for photos even when the only information
available is a stream or a few bytes allows sending arbitrary bytes
as photos, if force_document was not set to True explicitly.
* Create `_NOT_A_REQUEST` when needed. Currently, modifications
in the raised exception would be "global".
* `retries` parameters were actually attempts. This has been fixed
to actually be the amount of retries, so 0 now means don't retry.
* Helper function to deal with retries instead of using a range with
different styles every time.
Things like SQLAlchemy work correctly only for timezone-aware datetimes.
The returned TLObjects all have them, but those that are manually created
were missing them, so serializing the state into SQLAlchemy sessions failed.
These two occur when replying to an inline query with a photo and
InputBotInlineMessageMediaAuto empty message, and passing URLs to
PNGs that may not be accessible (i.e. 403 from pixiv).
The salt1 that is sent to the server requires an additional 32 bytes
of random data. It's easy to miss this requirement from reading the
tdesktop source, because this extension is done in a function called
`ValidateNewCloudPasswordAlgo`.
https://github.com/telegramdesktop/tdesktop/blob/2e5a0e056cdb40d61d487c6062bffe1a835f
6ddd/Telegram/SourceFiles/core/core_cloud_password.cpp#L210-L211
