Telegram Threads

Persistently associate each Telegram topic with its runtime session. The title, working directory, and last used conversation do not identify the destination.

Registration and identity

Store bot, chat, message_thread_id, runtime host, and session_id. Visible names are editable; topic identifiers only make sense within their chat.

Validate from.id, chat.id, and chat type according to the access model. In groups, apply an explicit policy for members and roles. Authorizing a person does not grant access to all chats where they participate.

Create or link topics through an authorized action. Persist the association after the Telegram response and deduplicate records. If the local write fails after creating the remote topic, reconcile the orphaned topic before repeating the creation.

Check support and configuration for private topics in the current API. If the topic is not available, report the failure and preserve the original destination. An unknown topic requires rejection or explicit registration.

Delivery and isolation

• Deduplicate entries by bot and update_id. Preserve stable ID, origin, destination, content, status, and attempts in a queue with bounded size and pending items. Use parameterized SQL.
• Confirm delivery when the runtime accepts the operation. Retry transient failures and definitively reject invalid requests.
• Record an output as sent after confirming the send. Its key includes runtime/host, session, and item to avoid local ID collisions.
• A gap between remote acceptance and local write allows duplicates. Use idempotency keys when available; otherwise, document at-least-once delivery and reconcile IDs before repeating actions with effects.
• Apply retries and progressive backoff per session, maintaining its order. A failure or writer conflict must be isolated from other conversations.

Responses, approvals, attachments, and interruptions retain the same scope. Reject approvals from another session, even if they come from the same user, and keep files associated with their conversation.

Reconnection

Distinguish registered topic, connected runtime, subscribed session, and active turn. Resume the existing session after restarting the daemon; a writer conflict requires resolving control of that session without changing its model or permissions.

Recover complete pending items, with pagination where appropriate. Publish final responses, excluding internal reasoning, tool outputs, and already delivered history. Persist state atomically with private permissions.

Verification

Test two topics and two hosts with repeated local IDs, unknown topics, restart between send and confirmation, duplicate records, cross approvals, and a busy session while another works. Use test data and preserve existing conversations.

Reference: https://core.telegram.org/bots/api#createforumtopic