# kcode-telegram-update-dispatch
`kcode-telegram-update-dispatch` provides bounded, keyed scheduling for Telegram updates. It owns dispatch mechanics only; callers retain update processing, persistence, polling cursors, identity, authorization, group policy, ingress, and delivery behavior.
## Public API
The crate exposes one cloneable type:
- `UpdateDispatcher::new(processor)` constructs a dispatcher from a callback that receives a `teloxide::types::Update` and returns a `Send + 'static` future yielding `anyhow::Result<()>`.
- `UpdateDispatcher::enqueue(update)` queues an update and returns once the update has been accepted for dispatch or reports that a per-principal or active-principal bound was reached.
Clones share queues, worker accounting, and concurrency limits.
## Dispatch keys
Updates are serialized by an internal principal key:
- Ordinary private-chat messages are keyed by the sending user.
- Ordinary group and supergroup messages are keyed by chat and sending user.
- Group-authored messages are keyed by chat. A message is group-authored when `sender_chat.id == message.chat.id` or `from.is_anonymous()`.
- Chat-member membership updates and chat migrations are keyed as group-control work for the affected chat.
- Updates without one of those identities use the `Other` key.
The key type is intentionally private. It is scheduling policy, not a public identity or authorization contract.
## Ordering and bounds
Each key has a FIFO `VecDeque`. At most 32 updates may wait for one key. At most 256 principal workers may be active. Processor execution is additionally bounded by a global semaphore with 16 permits.
A worker drains one key in order and removes its queue when drained. Different keys can progress independently, subject to the global limit.
## Failure isolation
A processor `Err` is logged with fixed safe metadata: the update ID and fixed text. The error value is never formatted. Processing then continues with the next queued update.
Processor-future panics are caught and logged with fixed safe text and the update ID. A panic therefore does not strand the key or prevent later queued updates from running.
## Compatibility and scope
The crate preserves the extracted keyed scheduling behavior. It does not classify database errors, retry requests, process updates, store polling state, enforce group security, or make Telegram provider calls. Hosts can keep those responsibilities in a compatibility wrapper around `UpdateDispatcher`.