[mysubcult]

What

One HTTP client for every Bot API call the extension makes (Longman\TelegramBot\Request::setClient, installed in run()):

• 429 Too Many Requests — Telegram allows a bot about 20 messages a minute in one group, so a burst of chats in the operators group can hit it. Telegram says how long to wait (parameters.retry_after); waits up to 10 seconds are honoured and the call is sent again (at most twice). Longer waits are not slept through — the call fails as before. A call is repeated only when its body can be read again (files are seekable streams), so file uploads are retried too.
• Refused calls are visible — today a 400/403/429 answer is only seen by the caller, and most callers just return. Now every 4xx/5xx goes to the audit log (System → Audit log, category telegram_api_error) as method: code description. The bot token (part of the URL) is never logged. Expected answers such as message is not modified are skipped.

Nothing changes for successful calls; base URI and timeouts are the same as the client Longman creates by default.

How

providers/TelegramApiClient.php: Guzzle HandlerStack::create() plus two middlewares — Middleware::retry (decider reads retry_after from the 429 body, delay = that wait) and a logging middleware. Both sit inside http_errors, so they see the 4xx as a response; callers still get the same exception/response as before.

Tested

• Mock transport: 429 (retry_after: 1) → waited 1 s → 200; 429 with retry_after: 60 → no retry, fails at once; 400 → logged, same exception as before.
• Real bot: getMe, replies, file upload; a send to a missing topic is logged as sendMessage: 400 Bad Request: message thread not found.

🤖 Generated with Claude Code