[Bug] ChosenInlineResult omits inline_message_id when the inline result uses InputRichMessageContent with rich buttons

[AAraKKe]

The docs say ChosenInlineResult.inline_message_id is "available only if there is an inline keyboard attached to the message". Since Bot API 10.3 buttons can also live inside rich message content (<tg-button-row>/<tg-button> in InputRichMessage.html), and messages sent this way behave inconsistently between the two update types:

• callback_query updates from taps on the in-content buttons carry inline_message_id, so the message clearly has one allocated.
• The chosen_inline_result update for the same message does not carry it.

I guess the original reasoning was that a message without a keyboard is one the bot can never interact with again, so there was no point in handing out an id for it. With rich buttons that assumption no longer holds: the message is just as interactive, its taps produce normal callback queries, and it can be edited through the id those carry. But the condition still only checks for a classic keyboard, so this looks like an oversight from the rich messages update rather than intended behavior.

Steps to reproduce

1. Answer an inline query with an InlineQueryResultArticle whose input_message_content is an InputRichMessageContent with a rich_message whose html includes a <tg-button-row> with a callback_data button. Do not set reply_markup.
2. Have a user pick the result (inline feedback enabled).
3. The chosen_inline_result update arrives without inline_message_id.
4. Tap the in-content button on the sent message: the resulting callback_query does carry inline_message_id.

Why it matters

chosen_inline_result is the only moment a bot can bind an inline message to its own state before users interact with it. With rich content buttons there is no way to learn the inline_message_id until someone presses a button, so bots that track or authorize their inline messages cannot move their inline results to rich buttons. The workaround for now is to keep a classic reply_markup on inline results, which defeats the point of rich buttons there.

Expected behavior

chosen_inline_result.inline_message_id is present whenever the sent message carries tappable rich buttons, same as callback_query already does.

[levlam]

The update chosen_inline_result isn't supposed to be used for anything besides statistics of usage. There are a lot of cases when it is impossible to send the update and it isn't sent at all. Therefore if the bot tries to use inline_message_id from the update for any functionality, it already breaks itself in many cases.

[AAraKKe]

Thanks @levlam. I understand delivery of chosen_inline_result is best-effort: it's gated on the inline feedback setting and there are cases where it can't be sent at all, and a bot has to tolerate that. That part is not in question.

But the documentation describes inline_message_id as more than a statistics field:

Optional. Identifier of the sent inline message. Available only if there is an inline keyboard attached to the message. Will be also received in callback queries and can be used to edit the message.

"Can be used to edit the message" is a documented functional use, and @mitupbot relies on it in that way: when the update is delivered, the id lets the bot track the shared message and keep it up to date as the underlying data changes. All of the bot's inline results carry a keyboard, so the documented condition has held consistently.

There is also a trust angle. Callback data is client-supplied and entity ids are guessable, so a button callback by itself can't prove a card was ever genuinely shared. A modified client can emit callbacks for meetings nobody shared with its user. chosen_inline_result is the only server-originated signal that a share actually happened, so @mitupbot registers shared messages from that update (running inline feedback at 100%) and refuses interaction on inline messages it has no record of. Best-effort delivery is compatible with that design because a missed update fails closed: the card is simply not honored.

My request isn't about delivery guarantees. It's about consistency within an update that was delivered: whether the id is present shouldn't depend on which button representation the message uses. A rich message with <tg-button> is as interactive as one with reply_markup, and the callback_query from it does carry the id. As it stands, a rich-button result can't participate in the scheme above at all, so the only safe way to build one is to keep a classic reply_markup on inline results, which defeats the purpose of using rich buttons on inline messages. The workaround we are using while reshaping the @mitupbot interface is to not adopt rich buttons in meeting shared cards. It makes the bot feel awkward though. the entire interaction with the bot happens in a more moder organized visualization but when the meeting is shared it is different.

I think chosen_inline_result should include inline_message_id when the chosen result contains rich buttons, matching the documented condition's intent.