Errors¶

The roots. Every error Telegram documents is also reachable by name from sunnygram.errors, generated from Telegram's own table with the published explanation as its docstring, and not listed here because there are 780 of them. See Errors for the shape of the tree and how to catch things.

Refusals¶

sunnygram.errors.rpc.RPCError ¶

Bases: SunnygramError

A call reached the server and came back refused.

sunnygram.errors.rpc.BadRequest ¶

Bases: RPCError

400, the call itself was wrong.

sunnygram.errors.rpc.Unauthorized ¶

Bases: RPCError

401, this key is not signed in.

sunnygram.errors.rpc.Forbidden ¶

Bases: RPCError

403, signed in but not allowed.

sunnygram.errors.rpc.NotFound ¶

Bases: RPCError

404, no such thing.

sunnygram.errors.rpc.NotAcceptable ¶

Bases: RPCError

406, the call was understood and the client is expected to know why.

Telegram answers this where showing the message to someone would be worse than saying nothing, so a client is meant to handle it quietly instead of put it on screen.

sunnygram.errors.rpc.InternalError ¶

Bases: RPCError

500 or 503, the server's problem. Worth retrying.

sunnygram.errors.rpc.Timeout ¶

Bases: RPCError

The server gave up waiting on itself. Worth retrying.

Waiting¶

sunnygram.errors.rpc.Flood ¶

Bases: RPCError

420, too much of something. Slow down.

sunnygram.errors.rpc.FloodWait ¶

Bases: Flood

Too many calls. Wait and try again.

sunnygram.errors.rpc.SlowmodeWait ¶

Bases: Flood

This chat has slow mode on, and it is not our turn yet.

sunnygram.errors.rpc.TakeoutInitDelay ¶

Bases: Flood

A data export was asked for and has to be approved first.

Migrations¶

sunnygram.errors.rpc.Migrate ¶

Bases: RPCError

The wrong datacenter was asked. The right one is in dc_id.

Signing in¶

sunnygram.errors.rpc.SessionPasswordNeeded ¶

Bases: Unauthorized

The code was right and there is a second factor to get past.

sunnygram.errors.rpc.PhoneCodeInvalid ¶

Bases: BadRequest

That is not the code that was sent.

sunnygram.errors.rpc.PhoneCodeExpired ¶

Bases: BadRequest

The code was right once. Ask for another.

sunnygram.errors.rpc.PhoneNumberInvalid ¶

Bases: BadRequest

That is not a phone number Telegram will accept.

sunnygram.errors.rpc.PasswordHashInvalid ¶

Bases: BadRequest

The second factor did not check out, so the password was wrong.

sunnygram.errors.rpc.AuthTokenExpired ¶

Bases: BadRequest

The login token timed out. Show a fresh one.

sunnygram.errors.rpc.AuthTokenInvalid ¶

Bases: BadRequest

The login token is not one this account can accept.

Everything else¶

sunnygram.errors.base.SunnygramError ¶

Bases: Exception

Base class for every error the library raises.

sunnygram.errors.base.TLError ¶

Bases: SunnygramError

Something went wrong encoding or decoding the binary TL format.

sunnygram.errors.base.TransportError ¶

Bases: SunnygramError

Something went wrong below MTProto, on the connection itself.

sunnygram.errors.base.SecurityError ¶

Bases: SunnygramError

A cryptographic check did not hold.

Always fatal. There is no safe way to carry on with data that failed one of these, so nothing catches it to retry.

sunnygram.errors.base.PeerNotFound ¶

Bases: SunnygramError

Nothing known can name this person or chat to the server.

MTProto refers to almost everyone by an id and an access hash together, and the hash is only ever learned by being told it. So this is not the server saying no: it is the client saying it has never seen this peer and has no way to ask about it. Resolving a username, or anything that makes the peer arrive alongside an update, fixes it for good.

sunnygram.errors.base.FileTooLarge ¶

Bases: SunnygramError

A download turned out to be bigger than the caller allowed for.

Building one¶

sunnygram.errors.rpc.rpc_error ¶

rpc_error(code: int, message: str, *, method: str | None = None) -> RPCError

Build the most specific error that fits what the server said.

An error the table has never heard of, which is what an error added since the last refresh looks like, comes back as its status code and keeps its message. Nothing is guessed from the shape of the name: a message merely ending in digits is not a message carrying a number.