chore(deps): bump github.com/go-telegram/bot from 1.21.0 to 1.25.0

[dependabot]

Bumps github.com/go-telegram/bot from 1.21.0 to 1.25.0.

Release notes

Sourced from github.com/go-telegram/bot's releases.

v1.25.0

• Fix: attachments nested in a rich message are uploaded. buildRequestForm had no case for InputRichMessage, so the field fell through to a plain json.Marshal and the attach:// references in InputRichMessage.Media and in the media InputRichBlock* blocks were serialized without their file parts, leaving Telegram nothing to resolve them against (#298).
• Fix: the thumbnail of an InputMedia is uploaded. InputFileUpload nested in an InputMediaVideo, InputMediaAnimation, InputMediaAudio, InputMediaDocument or InputPaidMediaVideo was encoded as "@<filename>", which is not a Bot API reference, and no file part was written, so the thumbnail was silently dropped by Telegram. It is now marshalled as attach://<filename> and uploaded under that name. InputFileUpload.MarshalJSON emits the same reference everywhere; at the top level of a request the field is still sent as its own form part, so that path is unchanged.
• Fix: a typed nil InputFile or InputMedia no longer panics while the form is built. A typed nil in a top level InputFile field, in InputMedia / InputPaidMedia (single or slice) or in InputRichMessage.Media is reported as an error, and a typed nil thumbnail nested in an InputMedia is omitted from the encoded media instead of being sent as a null the Bot API rejects.
• Fix: a nested InputFileUpload with an empty Filename is rejected. Filename is the attach:// reference and the part name, so an empty one produced "thumbnail":"attach://" and an opaque Bad Request from Telegram.
• Fix: InputFileUpload.MarshalJSON and InputFileString.MarshalJSON escape their value instead of concatenating it into a JSON string. A Filename or a file_id containing a quote or a backslash produced invalid JSON, failing the request after the file parts had already been streamed.
• [BREAKING] Fix: two different files sharing a part name are rejected with an error instead of both being written. The name of a part is what an attach:// reference resolves against, so a duplicate — most easily two thumbnails with the same Filename — silently made Telegram resolve both references to the first file. One file referenced from several entries under a single name still works: the part is written once and reused. A file part and a form field of the same name are the same ambiguity and are rejected too. A request that built before can now fail early, most visibly when an attach:// name matches the name of a form field, e.g. attach://media in sendMediaGroup, editMessageMedia or sendPaidMedia.

v1.24.0

• Support Bot API 10.3 (August 24, 2026 update):
  • Rich Messages: new RichMessageButton; RichTextButton (via the RichText union); RichBlockButtons, RichBlockExpandableBlockQuotation, RichBlockDocument and their InputRichBlock* counterparts (via the RichBlock / InputRichBlock unions); is_compact on RichBlockTable and InputRichBlockTable; tg://document?id= links for InputRichMessageMedia.
  • Ephemeral Messages: new EphemeralMessageParameters (with replace_callback_query_message), sent as ephemeral_message_parameters by the 13 send methods and sendRichMessage; rich_message on editEphemeralMessageText (and text made optional); show_caption_above_media on editEphemeralMessageCaption; upload of new files in editEphemeralMessageMedia; can_send_welcome_messages on

... (truncated)

Changelog

Sourced from github.com/go-telegram/bot's changelog.

v1.25.0 (2026-09-01)

• Fix: attachments nested in a rich message are uploaded. buildRequestForm had no case for InputRichMessage, so the field fell through to a plain json.Marshal and the attach:// references in InputRichMessage.Media and in the media InputRichBlock* blocks were serialized without their file parts, leaving Telegram nothing to resolve them against (#298).
• Fix: the thumbnail of an InputMedia is uploaded. InputFileUpload nested in an InputMediaVideo, InputMediaAnimation, InputMediaAudio, InputMediaDocument or InputPaidMediaVideo was encoded as "@<filename>", which is not a Bot API reference, and no file part was written, so the thumbnail was silently dropped by Telegram. It is now marshalled as attach://<filename> and uploaded under that name. InputFileUpload.MarshalJSON emits the same reference everywhere; at the top level of a request the field is still sent as its own form part, so that path is unchanged.
• Fix: a typed nil InputFile or InputMedia no longer panics while the form is built. A typed nil in a top level InputFile field, in InputMedia / InputPaidMedia (single or slice) or in InputRichMessage.Media is reported as an error, and a typed nil thumbnail nested in an InputMedia is omitted from the encoded media instead of being sent as a null the Bot API rejects.
• Fix: a nested InputFileUpload with an empty Filename is rejected. Filename is the attach:// reference and the part name, so an empty one produced "thumbnail":"attach://" and an opaque Bad Request from Telegram.
• Fix: InputFileUpload.MarshalJSON and InputFileString.MarshalJSON escape their value instead of concatenating it into a JSON string. A Filename or a file_id containing a quote or a backslash produced invalid JSON, failing the request after the file parts had already been streamed.
• [BREAKING] Fix: two different files sharing a part name are rejected with an error instead of both being written. The name of a part is what an attach:// reference resolves against, so a duplicate — most easily two thumbnails with the same Filename — silently made Telegram resolve both references to the first file. One file referenced from several entries under a single name still works: the part is written once and reused. A file part and a form field of the same name are the same ambiguity and are rejected too. A request that built before can now fail early, most visibly when an attach:// name matches the name of a form field, e.g. attach://media in sendMediaGroup, editMessageMedia or sendPaidMedia.

v1.24.0 (2026-08-26)

• Support Bot API 10.3 (August 24, 2026 update):
  • Rich Messages: new RichMessageButton; RichTextButton (via the RichText union); RichBlockButtons, RichBlockExpandableBlockQuotation, RichBlockDocument and their InputRichBlock* counterparts (via the RichBlock / InputRichBlock unions); is_compact on RichBlockTable and InputRichBlockTable; tg://document?id= links for InputRichMessageMedia.
  • Ephemeral Messages: new EphemeralMessageParameters (with replace_callback_query_message), sent as ephemeral_message_parameters by the 13 send methods and sendRichMessage; rich_message on editEphemeralMessageText (and text made optional);

... (truncated)

Commits

• 3d38d39 changelog: cut v1.25.0 for the attachment upload fixes
• 44cff36 fix: upload attachments nested in rich messages and InputMedia thumbnails (#299)
• 5842ef8 changelog: 429 retry_after, reply_to_story and delete-sent-messages fixes
• 7a43a65 fix(models): correct BusinessBotRights delete-sent-messages field (#286)
• 1400659 fix: correct reply_to_story field name and json tag on Message (#287)
• 2836b7b fix: honour retry_after on 429 in the getUpdates loop (#289)
• cacace1 fix: always send the required story rights in admin types
• 49a5abd changelog: date v1.24.0, add the attach:// nil reader fix
• 571c7a6 feat: support Bot API 10.3 (#295)
• d8a23e5 fix: return error for attach:// with a nil reader (#297)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)