fix(deps): update module github.com/go-telegram/bot to v1.27.0 - #149
Conversation
|
Important Review skippedBot user detected. To trigger a single review, invoke the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
 |
|
Overall Grade |
Security Reliability Complexity Hygiene |
Code Review Summary
| Analyzer | Status | Updated (UTC) | Details |
|---|---|---|---|
| Go |  |
Sep 11, 2026 5:29p.m. | Review ↗ |
Important
AI Review is run only on demand for your team. We're only showing results of static analysis review right now. To trigger AI Review, comment @deepsourcebot review on this thread.
This PR contains the following updates:
v1.25.0→v1.27.0Release Notes
go-telegram/bot (github.com/go-telegram/bot)
v1.27.0Compare Source
rawRequeststreamed the multipart body through an
io.Pipe, whichnet/httpcannot replay,so
Request.GetBodywas never set andhttp2.Transportfailed every POST inflight on a draining connection with
cannot retry err ... after Request.Body was written. Telegram drains connections routinely, and a bot on such a connectionkept receiving updates while every
sendMessage/editMessageText/answerCallbackQueryfailed until the connection was dropped. The body is nowbuilt into a buffer up front and handed over as a
*bytes.Reader, sonet/httpsets
ContentLengthandGetBodyand the transport retries transparently. Thetrade-off is that an upload is held in memory for the duration of the request
instead of being streamed (#275).
getMe,logOut,close, or a params struct whosefields are all omitted) is sent without a body and without a multipart
Content-Type. The pipe-based request always declared a multipart body, empty ornot, which local
telegram-bot-api --localservers reject with a bare400, sobot.Newagainst a local server failed withunexpected end of JSON input(#285, #224).
buildRequestFormcounts custom-marshaled fields (BotCommandScope,InlineQueryResult) andInputMediafields. They were written to the form butnot counted, so a request consisting only of such a field would have been sent
as empty.
v1.26.0Compare Source
models (
ChatMember,ReactionType,ChatBoostSource,OwnedGift,MenuButton,MessageOrigin,StoryAreaType,TransactionPartner,RevenueWithdrawalState,BackgroundType,BackgroundFill,RichBlock,RichText,PaidMedia) returnedunsupported <Type> typefromUnmarshalJSONwhen thetype/status/sourcevalue was not in their switch.
getUpdatesdecoded the whole batch with onejson.Unmarshal, so a single update carrying a value added by a Bot API releasefailed 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(SourceforChatBoostSource), leaves every variant pointer nil and returns no error, so aconsumer switching on
Typereaches its default branch instead of never seeing theupdate. The webhook path gets the same tolerance through the models.
MarshalJSON(ChatMember,ReactionType,ChatBoostSource,MenuButton,MessageOrigin,BackgroundType,BackgroundFill,RichBlock,RichText) encode an unknown discriminator as the bare{"type":"<Type>"}(status/sourcewhere applicable) instead of returningunsupported <Type> type, so an update that is logged, persisted or queued as JSONstill 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.
{}, or aChatMemberwithoutstatus) is rejected byUnmarshalJSONin all fourteen unions. It is a malformedvalue rather than a variant from a future release, and
MarshalJSONrejects anempty
Typeon the way back out, so accepting it would produce values that decodebut cannot be encoded again. For
RichTextan emptyTypeis also its plain-stringform, so
{"text":"hi"}would otherwise have decoded to an empty string.ReactionType.MarshalJSONhandlespaid. The variant has been decodable sinceBot API 7.6 but had no marshal case, so a paid reaction read from an update could not
be encoded back, e.g. into
setMessageReaction. All threeReactionTypevariants nowgo through the shared
marshalVariant, so aTypeset without its variant pointerreturns an error instead of panicking inside
encoding/json.getUpdatesdecodes each update on its own. An update that still fails todecode is reported through the errors handler with its
update_idand its rawpayload, the offset moves past it, and the rest of the batch is delivered. When the
last update of a batch has no readable
update_id(an unparsable id, anullelement, an object without the field) the offset cannot move and the same batch comes
back, so the poll backs off (100ms..5s, one step per request) as it does on a failed
request, instead of re-requesting it in a tight loop. Such an element is reported
and never delivered, and no longer resets the offset to zero.
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.