Skip to content

fix(history): batch getHistory requests instead of one RPC per message#249

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

fix(history): batch getHistory requests instead of one RPC per message#249
yagop wants to merge 1 commit into
gotd:mainfrom
yagop:fix/history-batch-size

Conversation

@yagop

@yagop yagop commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

Problem

tg history --limit N is extremely slow for anything beyond a handful of messages — fetching ~350 messages did not finish in 7 minutes.

The cause is in listHistory: the gotd messages iterator is created with query.Messages(api).GetHistory(peer).Iter(), leaving the builder's default batch size of 1. The iterator therefore issues one messages.getHistory RPC per message (hundreds of round trips for a few hundred messages).

Fix

Set BatchSize(max(1, min(limit, 100))) on the builder:

  • 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), so 100 is the safe maximum.
  • Clamp to ≥ 1 — a non-positive batch size panics the iterator (NewIterator preallocates a slice with that capacity), so a negative --limit would otherwise crash the process.

Fetching 350 messages now takes ~3.5s (≈4 RPCs) instead of timing out.

Tests

Adds TestListHistoryBatchSize, asserting the per-request limit sent is 5/100/100 for --limit 5/100/350 and clamps to 1 for --limit 0/-1 (no panic).

🤖 Generated with Claude Code

The messages iterator's default batch size is 1, so `tg history --limit N`
issued one messages.getHistory RPC per message. Larger limits became
extremely slow (hundreds of round trips for a few hundred messages).

Set BatchSize to min(limit, 100): Telegram does not reject a per-request
limit above 100 but silently returns fewer/incorrect results, so 100 is the
safe maximum. Clamp 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