GenServer that polls Telegram for updates and routes them to Sexy.Bot.Session callbacks.
Started automatically as a child of Sexy.Bot. Each incoming update is dispatched
through Sexy.Bot.Dispatcher partitions, so a malformed update or a crashing
handler can never kill the polling loop.
Delivery semantics
Updates are confirmed to Telegram on the poll after they were dispatched, and the
offset survives poller restarts — so delivery is at-least-once: after a crash in
the confirmation window a batch can be dispatched twice. Handlers with side effects
(payments!) should be idempotent, e.g. deduplicate by update_id.
Updates of the same chat are processed in order (they land in the same dispatcher partition); different chats run concurrently.
Routing rules
| Update type | Condition | Session callback |
|---|---|---|
message | text starts with / | handle_command/1 |
message | otherwise | handle_message/1 |
callback_query | data starts with /_delete | built-in: deletes the message |
callback_query | data starts with /_transit | built-in: deletes + handle_transit/3 |
callback_query | otherwise | handle_query/1 |
message | has successful_payment | handle_successful_payment/1 |
pre_checkout_query | — | handle_pre_checkout/1 |
poll / poll_answer | — | handle_poll/1 |
my_chat_member | — | handle_chat_member/1 |
Built-in routes
/_delete mid=<id>— deletes message with given id, answers the callback/_transit mid=<id>-cmd=<command>-...— deletes message, answers callback, then callsSession.handle_transit(chat_id, command, query_params)
Callback data is client-controlled: malformed built-in routes (missing mid/cmd)
are answered with a no-op instead of raising.
Summary
Functions
Returns a specification to start this module under a supervisor.
Callback implementation for GenServer.init/1.
Functions
Returns a specification to start this module under a supervisor.
See Supervisor.
Callback implementation for GenServer.init/1.