Skip to content

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

Merged
davidramiro merged 1 commit into
masterfrom
dependabot/go_modules/github.com/go-telegram/bot-1.27.0
Sep 18, 2026
Merged

davidramiro merged 1 commit into
masterfrom
dependabot/go_modules/github.com/go-telegram/bot-1.27.0

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Sep 14, 2026

Copy link
Copy Markdown
Contributor

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

Release notes

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

v1.27.0

  • Fix: a request can be retried by HTTP/2 after the server sends GOAWAY. rawRequest streamed the multipart body through an io.Pipe, which net/http cannot replay, so Request.GetBody was never set and http2.Transport failed every POST in flight on a draining connection with cannot retry err ... after Request.Body was written. Telegram drains connections routinely, and a bot on such a connection kept receiving updates while every sendMessage / editMessageText / answerCallbackQuery failed until the connection was dropped. The body is now built into a buffer up front and handed over as a *bytes.Reader, so net/http sets ContentLength and GetBody and the transport retries transparently. The trade-off is that an upload is held in memory for the duration of the request instead of being streamed (#275).
  • Fix: a method without fields (getMe, logOut, close, or a params struct whose fields are all omitted) is sent without a body and without a multipart Content-Type. The pipe-based request always declared a multipart body, empty or not, which local telegram-bot-api --local servers reject with a bare 400, so bot.New against a local server failed with unexpected end of JSON input (#285, #224).
  • Fix: buildRequestForm counts custom-marshaled fields (BotCommandScope, InlineQueryResult) and InputMedia fields. They were written to the form but not counted, so a request consisting only of such a field would have been sent as empty.

v1.26.0

  • Fix: an unknown polymorphic discriminator no longer stalls long polling. Fourteen models (ChatMember, ReactionType, ChatBoostSource, OwnedGift, MenuButton, MessageOrigin, StoryAreaType, TransactionPartner, RevenueWithdrawalState, BackgroundType, BackgroundFill, RichBlock, RichText, PaidMedia) returned unsupported <Type> type from UnmarshalJSON when the type / status / source value was not in their switch. getUpdates decoded the whole batch with one json.Unmarshal, so a single update carrying a value added by a Bot API release failed the entire call, the offset never advanced, and the same batch was requested and rejected forever. The wrapper now keeps the raw value in Type (Source for ChatBoostSource), leaves every variant pointer nil and returns no error, so a consumer switching on Type reaches its default branch instead of never seeing the update. The webhook path gets the same tolerance through the models.
  • Fix: the nine unions with a MarshalJSON (ChatMember, ReactionType, ChatBoostSource, MenuButton, MessageOrigin, BackgroundType, BackgroundFill, RichBlock, RichText) encode an unknown discriminator as the bare {"type":"<Type>"} (status / source where applicable) instead of returning unsupported <Type> type, so an update that is logged, persisted or queued as JSON still encodes on the day Telegram ships a new variant. Only the discriminator survives: no variant was populated, so the other fields of the unknown object are not kept and are not written back. The remaining five unions have no custom encoder and are unchanged.
  • Fix: a tagged object without a discriminator ({}, or a ChatMember without status) is rejected by UnmarshalJSON in all fourteen unions. It is a malformed value rather than a variant from a future release, and MarshalJSON rejects an

... (truncated)

Changelog

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

v1.27.0 (2026-09-11)

  • Fix: a request can be retried by HTTP/2 after the server sends GOAWAY. rawRequest streamed the multipart body through an io.Pipe, which net/http cannot replay, so Request.GetBody was never set and http2.Transport failed every POST in flight on a draining connection with cannot retry err ... after Request.Body was written. Telegram drains connections routinely, and a bot on such a connection kept receiving updates while every sendMessage / editMessageText / answerCallbackQuery failed until the connection was dropped. The body is now built into a buffer up front and handed over as a *bytes.Reader, so net/http sets ContentLength and GetBody and the transport retries transparently. The trade-off is that an upload is held in memory for the duration of the request instead of being streamed (#275).
  • Fix: a method without fields (getMe, logOut, close, or a params struct whose fields are all omitted) is sent without a body and without a multipart Content-Type. The pipe-based request always declared a multipart body, empty or not, which local telegram-bot-api --local servers reject with a bare 400, so bot.New against a local server failed with unexpected end of JSON input (#285, #224).
  • Fix: buildRequestForm counts custom-marshaled fields (BotCommandScope, InlineQueryResult) and InputMedia fields. They were written to the form but not counted, so a request consisting only of such a field would have been sent as empty.

v1.26.0 (2026-09-11)

  • Fix: an unknown polymorphic discriminator no longer stalls long polling. Fourteen models (ChatMember, ReactionType, ChatBoostSource, OwnedGift, MenuButton, MessageOrigin, StoryAreaType, TransactionPartner, RevenueWithdrawalState, BackgroundType, BackgroundFill, RichBlock, RichText, PaidMedia) returned unsupported <Type> type from UnmarshalJSON when the type / status / source value was not in their switch. getUpdates decoded the whole batch with one json.Unmarshal, so a single update carrying a value added by a Bot API release failed the entire call, the offset never advanced, and the same batch was requested and rejected forever. The wrapper now keeps the raw value in Type (Source for ChatBoostSource), leaves every variant pointer nil and returns no error, so a consumer switching on Type reaches its default branch instead of never seeing the update. The webhook path gets the same tolerance through the models.
  • Fix: the nine unions with a MarshalJSON (ChatMember, ReactionType, ChatBoostSource, MenuButton, MessageOrigin, BackgroundType, BackgroundFill, RichBlock, RichText) encode an unknown discriminator as the bare {"type":"<Type>"} (status / source where applicable) instead of returning unsupported <Type> type, so an update that is logged, persisted or queued as JSON still encodes on the day Telegram ships a new variant. Only the discriminator survives: no variant was populated, so the other fields of the unknown object are not kept and are not written back. The remaining five unions have no custom encoder and are unchanged.
  • Fix: a tagged object without a discriminator ({}, or a ChatMember without status) is rejected by UnmarshalJSON in all fourteen unions. It is a malformed value rather than a variant from a future release, and MarshalJSON rejects an

... (truncated)

Commits
  • 6215b5e changelog: date v1.27.0
  • 62994f8 fix: build the request body up front so HTTP/2 can retry after GOAWAY (#275)
  • 7bbddd4 changelog: date v1.26.0
  • edea494 fix: tolerate unknown polymorphic types and skip undecodable updates in getUp...
  • 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)
  • Additional commits viewable in compare view

Dependabot compatibility score

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)

Bumps [github.com/go-telegram/bot](https://github.com/go-telegram/bot) from 1.21.0 to 1.27.0.
- [Release notes](https://github.com/go-telegram/bot/releases)
- [Changelog](https://github.com/go-telegram/bot/blob/main/CHANGELOG.md)
- [Commits](go-telegram/bot@v1.21.0...v1.27.0)

---
updated-dependencies:
- dependency-name: github.com/go-telegram/bot
  dependency-version: 1.27.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file go Pull requests that update go code labels Sep 14, 2026
@davidramiro
davidramiro merged commit 3033e32 into master Sep 18, 2026
1 check passed
@dependabot
dependabot Bot deleted the dependabot/go_modules/github.com/go-telegram/bot-1.27.0 branch September 18, 2026 16:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file go Pull requests that update go code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant