Documentation menu
Getting started
New in v2.0
Feature deep dives
Reference
Ordered delivery
Ordered Durable Telegram Delivery Queue
Lease-based durable workers, per-channel delivery lanes that preserve post order, atomic cursor persistence, retry with jitter, and no duplicate sends.
Verified against the checkout built for v2.2.4 · updated 20 Oct 2026
On this page
ReliabilityNew in v2.0
Ordering is per channel lane, so parallelism never reshuffles a conversation.
Lanes, not a free-for-all
Posts from one source channel are assigned to that channel's delivery lane. Within a lane, order is preserved; across lanes, work runs in parallel. That is what lets a ten-message burst come out in the right sequence while three other channels are being served at the same time.
This is why a busy multi-source task does not interleave two channels' posts, and why a retry of an older message never overtakes a newer one in the same lane.
- Per-channel ordering with parallel execution across channels.
- Lease-based jobs: a worker holds a job for a bounded time, so a crashed worker releases work instead of stranding it.
- Exponential backoff with jitter, so retries do not synchronise into a thundering herd.
- Backpressure control: the queue depth and in-flight count are visible, and new work defers rather than failing.
Cursor persistence that cannot race
The channel cursor records how far a source has been read. Persisting it non-atomically meant the poller and the connection could both write, and a crash between the two could skip or repeat messages. Cursors are now persisted atomically, which removed the last source of double delivery in the poller path.
When Telegram says slow down
| Event | Behaviour |
|---|---|
| FloodWait | The affected account pauses, the queue stops consuming for that account, and delivery resumes automatically when the limit expires. |
| CHAT_WRITE_FORBIDDEN | The task is auto-disabled instead of retrying into a channel that will never accept it. |
| Transient network error | Retry with backoff and jitter, up to the configured attempt limit. |
| Unconfirmed timeout | Job becomes OUTCOME_UNCONFIRMED and is visible in the DLQ for replay. |
| Edited source message | Delivered copies are edited in place; policy is re-evaluated and stale edits are ignored beyond max_time_edit. |
Watching the queue
atf data queue # depth per state, leases, retry waits
atf data stats # throughput and outcome counters
atf status --watch # live board: services, ports, tasks
atf watch # continuous supervisionFrequently asked
Is delivery exactly-once?
No system can promise that against Telegram. This one promises order within a channel lane, atomic cursor persistence, content deduplication, and an explicit OUTCOME_UNCONFIRMED state instead of silent ambiguity.
What happens to queued jobs when I pause a task?
They are deferred with backoff rather than failed, and resume unblocks retry-wait jobs when you turn the task back on.
Can I limit throughput to protect an account?
Yes — per-target delays and scheduling windows throttled delivery, and FloodWait handling pauses an account automatically when Telegram asks for it.