Skip to content

fix(chats,drafts): batch getDialogs requests instead of one RPC per dialog#250

Open
yagop wants to merge 1 commit into
gotd:mainfrom
yagop:fix/dialogs-batch-size
Open

fix(chats,drafts): batch getDialogs requests instead of one RPC per dialog#250
yagop wants to merge 1 commit into
gotd:mainfrom
yagop:fix/dialogs-batch-size

Conversation

@yagop

@yagop yagop commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

Problem

tg chats list and tg drafts are slow for the same reason as #249, in a different command: the gotd dialogs iterator is created without a batch size, leaving the builder's default of 1. It therefore issues one messages.getDialogs RPC per dialog.

  • tg chats list — one round trip per chat, up to --limit (default 100).
  • tg drafts — worse: listDrafts scans every dialog in the account with no limit to find the ones with a draft, so it walks the whole list one round trip at a time.

Fix

Set BatchSize on the builder:

  • chatsmax(1, min(limit, 100)), respecting --limit.
  • drafts — flat 100 (full scan, no user-facing limit).

Cap at 100 — Telegram does not reject a per-request limit above 100 but silently returns fewer/incorrect results (see gotd's own BatchSize doc; verified empirically against messages.getHistory — requesting 150/200 returns exactly 100), so 100 is the safe maximum. Clamp to ≥ 1 (chats) — a non-positive batch size panics the iterator (NewIterator preallocates a slice with that capacity), so a negative --limit would otherwise crash the process.

Tests

  • TestListChatsBatchSize — asserts the per-request limit sent is 5/100/100 for --limit 5/100/350 and clamps to 1 for 0/-1 (no panic).
  • TestListDraftsBatchSize — asserts the dialog scan requests 100 per RPC.

Companion to #249 (same class of bug; GetHistory there, GetDialogs here).

🤖 Generated with Claude Code

…ialog

The dialogs iterator's default batch size is 1, so it issued one
messages.getDialogs RPC per dialog. `tg chats list` was slow (one round trip
per chat up to --limit) and `tg drafts` was worse: it scans every dialog in
the account with no limit, so it walked the whole list one RPC at a time.

Set BatchSize: min(limit, 100) for chats (respecting --limit) and a flat 100
for drafts (full scan, no user limit). Telegram does not reject a per-request
limit above 100 but silently returns fewer/incorrect results, so 100 is the
safe maximum. chats clamps to at least 1, since a non-positive batch size
panics the iterator (it preallocates a slice with that capacity) and a
negative --limit would otherwise crash the process.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant