editMessageText >> no cusom emoji when editing rich_message

[MorozovNyam]

Hello everyone

def edit_message(self, message, rich_text, **commandDict):
        command = "editMessageText"

        chat_id = commandDict.get("chat_id")
        if not chat_id:
            chat_id = self.reserved_chat_id

        result = self.request(
            command,
            chat_id=chat_id,
            rich_message={
                "html": rich_text,
            },
            message_id=message.get("message_id") if message.get("message_id") else message,
            **commandDict
        )
        return result["result"]

when i call edit_message and in my new rich_text appears <tg-emoji emoji-id="5429326871076571411">🙂</tg-emoji>, bot api changes this premium emoji to alternative emoji of this custom emoji (not 🙂). i have telegram premium (when i use sendRichMessage telegram send message with premium emoji)

[AyacksRH]

Ran into the same thing and spent way too long on it, so dumping what I found.

It's my bot and I have Premium on the account that owns it. No Fragment username on the bot, just the regular BotFather one.

sendRichMessage with tg-emoji tags inside a table cell works fine, they come back as custom_emoji nodes in rich_message.blocks.

Then editMessageText on that same message, same html, same emoji ids, and they're just gone. ok:true, no error, nothing in the response to say why. Every custom_emoji got swapped for its alternative_text. The table survived, align survived, bold survived, emoji didn't.

The thing that convinced me it's the rich path and not the Premium rule: the exact same tg-emoji tags in a plain editMessageText with parse_mode HTML edit fine. Did three edits in a row on one message and entities came back with all of them every time.

Before writing this I tried my own sticker set and somebody else's, no difference. Tried paragraph, heading, footer, details, blockquote, list, pre, table cell. Tried entities instead of html. Tried img src="tg://emoji?id=..." which turns into the same node anyway. Tried editing a classic message into a rich one and back the other way. Stripped in all of them.

So is this on purpose, or did the edit path just never get the check that send has? And if it is on purpose, does buying an extra username on Fragment (the 6.7 thing) cover editing too or only sending? Asking because the only way to test that from my side is 1000 TON and I'd rather not find out the expensive way.

[AyacksRH]

One more data point that narrows it down a bit.

Skipped the html parser and used the blocks form instead, with the custom_emoji nodes written out as plain json. sendRichMessage kept all 8 of them. editMessageText with those exact same blocks came back with 0. Ran the edit twice, 0 both times.

So it's not the html parsing. Same json going in, same code path all the way down, and the only thing that differs is which method you call.

[MorozovNyam]

Most likely, the edit logic on Telegram server checks ONLY for paid username with TON. Cool devs if thats true)

[AyacksRH]

That was my first thought too, but the numbers don't back it. My bot has no Fragment username, and a plain editMessageText with parse_mode HTML keeps custom emoji across edits without complaining once. Three edits in a row on one message, all of them survived. Only the rich path drops them.

So the username isn't the gate. And if it ever turns out to be one, that's a strange thing to be selling. Sending is already free. Editing a normal message is already free. The only thing 1000 TON would buy you is the right to have those two behave the same way in a third place, and there isn't a line anywhere in the docs saying they shouldn't.

That's the part that bothers me more than the bug itself. The exact same nodes are accepted or quietly deleted depending on which method name you typed. No error, no warning, no mention of it anywhere. It's hard to build anything on a surface that changes its mind in silence and then charges you for the privilege of finding out.