Telegram error 400: Bad Request: message is not modified

You asked Telegram to edit a message, and the new text, entities and reply markup are byte-for-byte identical to what the message already contains. Telegram rejects no-op edits rather than silently accepting them, and returns the long description above. In practice the shorter prefix message is not modified is what most libraries match on.

This is the most harmless 400 in the whole API and also the noisiest. Menu bots that re-render an inline keyboard on every callback, pagination that lands on the same page, and 'refresh' buttons all trigger it constantly. Nothing is broken; the user simply sees no change, which is what they would have seen anyway.

Where it becomes a real bug is when your code treats any 400 as fatal and aborts the handler, so the answerCallbackQuery that should follow never runs and the user's button spinner hangs until the query expires with query is too old.

Library behavior differs enough to matter here. python-telegram-bot raises telegram.error.BadRequest; the common idiom is to catch it and check for "Message is not modified" in the message string. aiogram v3 raises TelegramBadRequest, matched the same way. grammY and Telegraf hand you the description on the error object (err.description), and node-telegram-bot-api on error.response.body.description. Comparison is against the parsed result, so two different markup strings that produce identical entities (say, the same bold text written in HTML and MarkdownV2) still count as 'not modified'.

Reproducing it takes one button: send a message with an inline keyboard whose handler edits the message to the same text, tap it twice, and the second tap fails with this description. That determinism is also what makes it safe to suppress: the failure carries no information beyond 'nothing changed', so treating it as success never hides a real fault.

{"ok":false,"error_code":400,"description":"Bad Request: message is not modified: specified new message content and reply markup are exactly the same as a current content and reply markup of the message"}

Keep a hash of the last rendered content per message and short-circuit identical renders. Structure callback handling as 'answer first, edit second', so UI feedback never depends on the edit result. Exclude this description from error alerting; it is noise, not a fault. The related editing rules (what a bot may edit, and the 48-hour rule for business messages) are collected under editing and deleting limits.