Skip to content

Add support for sending rich messages (Bot API 10.1)#5263

Closed
Phil9l wants to merge 3 commits into
python-telegram-bot:masterfrom
Phil9l:api-10.1-rich-messages
Closed

Add support for sending rich messages (Bot API 10.1)#5263
Phil9l wants to merge 3 commits into
python-telegram-bot:masterfrom
Phil9l:api-10.1-rich-messages

Conversation

@Phil9l

@Phil9l Phil9l commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

What

This adds the sending side of the Bot API 10.1 rich messages feature:

  • New InputRichMessage class (html / markdown / is_rtl / skip_entity_detection).
  • Bot.send_rich_message and Bot.send_rich_message_draft, with the matching ExtBot overrides and camelCase aliases.
  • Docs page + at-tree entry, unit tests for the new class, and offline tests for the two methods.

Scope (draft)

Bot API 10.1 is large; this PR is deliberately scoped to the send path so it stays reviewable, mirroring how a Bot API version is usually split into slices. Intentionally not included here (happy to follow up, or fold into a coordinated 10.1 branch):

  • Receiving side: RichMessage, RichBlock*, RichText*, and Message.rich_message.
  • editMessageText's rich_message parameter.
  • InputRichMessageContent for inline results.
  • BOT_API_VERSION is not bumped (other 10.1 additions are out of scope), so test_official is expected to stay red until the full version lands.

Testing / checks

  • tests/test_inputrichmessage.py (slots, to_dict, de_json, equality) and offline test_send_rich_message / test_send_rich_message_draft in tests/test_bot.py.
  • The test_camel_case_aliases, test_ext_bot_signature and related meta-tests pass for the new methods.
  • ruff check / ruff format clean; mypy introduces no new errors on the changed source.
  • .. versionadded:: NEXT.VERSION used throughout.

Opening as a draft for discussion on scope/approach before completing the rest of 10.1. Changelog fragment to follow once a PR number exists.

🤖 Generated with Claude Code

Phil9l and others added 2 commits June 12, 2026 10:51
Implement the sending side of the Bot API 10.1 "rich messages" feature:

- New ``InputRichMessage`` class describing a rich message to send.
- ``Bot.send_rich_message`` and ``Bot.send_rich_message_draft`` methods,
  with the corresponding ``ExtBot`` overrides and camelCase aliases.

The receiving-side classes (``RichMessage``, ``RichBlock*``, ``RichText*``),
``Message.rich_message``, the ``editMessageText`` ``rich_message`` parameter
and ``InputRichMessageContent`` are intentionally left for follow-up changes,
mirroring how a Bot API version is usually split into reviewable slices.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@tymrtn

tymrtn commented Jun 18, 2026

Copy link
Copy Markdown

Thanks for opening this. I noticed the overlap after opening #5275 for the same Bot API 10.1 Rich Messages send-side surface.

I’m happy to defer to maintainer preference on merge order, but for coordination: #5275 covers a few pieces that may be useful to fold into whichever PR maintainers prefer as the base:

  • InputRichMessageContent export/docs integration for inline content usage
  • Chat.send_rich_message / Chat.send_rich_message_draft
  • User.send_rich_message / User.send_rich_message_draft
  • Message.reply_rich_message
  • docs tree entries for both new input classes
  • a Chango fragment tied to the PR
  • focused tests for the shortcuts and input content class

If maintainers prefer this PR as the base, I can help port the missing pieces here rather than keeping two competing PRs open. If #5275 is easier to review because it already includes the shortcut/docs surface, I’m also happy to continue there and adjust scope as requested.

Either way, I’d like to avoid duplicating effort and get the initial send-side slice landed cleanly before tackling the full RichText* / RichBlock* hierarchy.

@tymrtn

tymrtn commented Jun 18, 2026

Copy link
Copy Markdown

I opened a small PR against this branch with the pieces from #5275 that don't overlap with your existing implementation: Phil9l#1

It keeps your InputRichMessage, Bot.send_rich_message, Bot.send_rich_message_draft, ExtBot, changelog, and existing tests intact, and adds only:

  • InputRichMessageContent
  • docs tree entries / inline content docs mention
  • Chat / User rich-message shortcuts
  • Message.reply_rich_message
  • focused shortcut + content tests

Focused checks passed locally:

python -m pytest -o 'addopts=' tests/test_inputrichmessage.py tests/test_bot.py tests/test_chat.py tests/test_user.py tests/test_message.py -k 'rich_message or inputrichmessage' -q
# 34 passed, 2814 deselected

python -m ruff check src/telegram/_inputrichmessage.py src/telegram/_chat.py src/telegram/_inline/inputmessagecontent.py src/telegram/_message.py src/telegram/_user.py tests/test_inputrichmessage.py tests/test_chat.py tests/test_message.py tests/test_user.py
# All checks passed

python -m ruff format --check src/telegram/_inputrichmessage.py src/telegram/_chat.py src/telegram/_inline/inputmessagecontent.py src/telegram/_message.py src/telegram/_user.py tests/test_inputrichmessage.py tests/test_chat.py tests/test_message.py tests/test_user.py
# 9 files already formatted

If you'd rather not take a PR into your fork, I can also squash/format it as a plain patch here.

@Phil9l

Phil9l commented Jun 18, 2026

Copy link
Copy Markdown
Contributor Author

Thanks @tymrtn — really appreciate you coordinating here rather than letting two PRs race on this.

I've merged your fork PR into this branch (rebased, so your commit keeps your authorship), and #5263 now covers the full send-side surface:

  • InputRichMessage + Bot.send_rich_message / send_rich_message_draft + ExtBot (already here)
  • InputRichMessageContent
  • Chat.send_rich_message / Chat.send_rich_message_draft
  • User.send_rich_message / User.send_rich_message_draft
  • Message.reply_rich_message
  • docs tree entries for both input classes + inline content mention
  • focused tests for the shortcuts and the content class

This stays scoped to the send path — no RichText* / RichBlock* receiving hierarchy and no BOT_API_VERSION bump yet — so test_official is expected to stay red until the full 10.1 lands.

Maintainers — if you're happy to use this as the single base for the 10.1 send-side slice, I'd suggest consolidating here and closing #5275 to avoid the duplicate. Happy to adjust scope either way.

@tymrtn

tymrtn commented Jun 18, 2026

Copy link
Copy Markdown

Follow-up helper PR for CI scope: Phil9l#2

It keeps this PR as the send-side slice and makes test_official explicit about what remains out of scope for Bot API 10.1:

  • full receive-side RichText* / RichBlock* hierarchy
  • RichMessage
  • Link / InputMediaLink
  • join request query methods/fields
  • editMessageText rich-message editing changes
  • other newly scraped 10.1 fields not implemented here

It also applies the Chango filename/content that CI requested, avoiding the failed bot push into the fork.

Local checks on top of current #5263 head:

TEST_OFFICIAL=true PYTHONPATH=src python -m pytest -o 'addopts=' tests/test_official/test_official.py -q
# 481 passed

python -m pytest -o 'addopts=' tests/test_inputrichmessage.py tests/test_bot.py tests/test_chat.py tests/test_user.py tests/test_message.py -k 'rich_message or inputrichmessage' -q
# 34 passed, 2814 deselected

python -m ruff check tests/test_official/exceptions.py tests/test_official/scraper.py
# All checks passed

python -m ruff format --check tests/test_official/exceptions.py tests/test_official/scraper.py
# 2 files already formatted

git diff --check
# clean

This should make the CI signal match the stated scope rather than pressuring this PR to become the whole 10.1 implementation.

@harshil21 harshil21 closed this Jun 18, 2026
@harshil21

Copy link
Copy Markdown
Member

Closing b/c after the refactor most of this would have to be redone. See #5261 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants