You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bug: Persian taker message not delivered due to Telegram MarkdownV2 parse error — proposed fallback fix #882
When a user with language set to Persian (fa) takes an order, the bot sometimes does not send the taker message. Root cause: the Persian translation for the key you_took_someone_order can contain characters that break Telegram's MarkdownV2 parsing, causing bot.telegram.sendMessage(...) to throw and the message not to reach the taker.
Reproduction
Set a Telegram user language to Persian (fa) in the bot.
Publish an order (sell/buy) and have another user take it.
Observe that the taker (buyer/seller) does not receive the "you took order" message and logs show a MarkdownV2 parse-related error.
Proposed fix
Wrap the sendMessage call in beginTakeSellMessage with a try/catch that:
first attempts to send with parse_mode: 'MarkdownV2' (preserve intended formatting for safe locales),
on failure retries once without parse_mode as a safe fallback.
Minimal patch (applies to bot/messages.ts, function beginTakeSellMessage):
I tried to replicate this issue with the taker in Farsi and the maker in another language, then the maker in Farsi and the taker in another language, and finally both in Farsi. I couldn't reproduce the problem on current main (HEAD), so I dug a bit deeper.
You mentioned the taker message is "sometimes" not sent, which makes me suspect this isn't actually related to MarkdownV2 escaping — the string you_took_someone_order in locales/fa.yaml is already properly escaped since #872, and I confirmed via logging that the message is built correctly and delivered successfully in every scenario I tried.
My biggest suspicion is that the real cause lies elsewhere: in beginTakeSellMessage (bot/messages.ts), the sendMessage call to notify the taker is wrapped in a try/catch that only calls logger.error(error) on failure, with no retry and no alert to anyone. So if the send fails for any reason — Telegram flood control (429), a transient network error, or anything else that throws inside that block — the order still gets saved as taken in the DB, but the taker never receives the message and nobody is notified that it failed.
Could it be that this issue isn't actually caused by the MarkdownV2 problem, but by this other failure mode instead? If you have logs or a screenshot from when you saw the error, that would help a lot narrowing it down.
Anyway, happy to help dig into this further if anything else comes up!
Thank u fot looking into the issue. Honestly i'm a non-techy user just trying to report ehat my selliw persian users have been experiencing fir the couple months ago. Here's one example:
Here, the taker took the above sell order a couple of times while lang was set to farsi, and the bot doesn't respond, then sends a message that says "no invoice was sent ..."
Then, when lang is set to eng by the taker, problem is solved.
Screenshot messages Date: 5 Aug 2026 - 14:55 (UTC+3:30)
I'd like to take this one. I traced it on current main: beginTakeSellMessage already wraps its sends in a try/catch, but the catch only logs — so when the MarkdownV2 send of you_took_someone_order throws, the taker message is silently lost, exactly as described.
This complements the merged #872 (which escaped reserved chars in the Farsi locale) rather than replacing it: escaping is fragile (any new unescaped char reintroduces the bug), whereas the proposed retry-without-parse_mode fallback guarantees the taker still receives the message even if a translation slips through. Same resilience principle I'm applying in #595 (a send failure to one party shouldn't drop the message).
I'll wrap just the you_took_someone_order send with the MarkdownV2→plain fallback and add a regression test. Could you assign it to me?
Activity
Matobi98 commentedon Aug 1, 2026
Hi @mgatmiri,
I tried to replicate this issue with the taker in Farsi and the maker in another language, then the maker in Farsi and the taker in another language, and finally both in Farsi. I couldn't reproduce the problem on current main (HEAD), so I dug a bit deeper.
You mentioned the taker message is "sometimes" not sent, which makes me suspect this isn't actually related to MarkdownV2 escaping — the string you_took_someone_order in locales/fa.yaml is already properly escaped since #872, and I confirmed via logging that the message is built correctly and delivered successfully in every scenario I tried.
My biggest suspicion is that the real cause lies elsewhere: in beginTakeSellMessage (bot/messages.ts), the sendMessage call to notify the taker is wrapped in a try/catch that only calls logger.error(error) on failure, with no retry and no alert to anyone. So if the send fails for any reason — Telegram flood control (429), a transient network error, or anything else that throws inside that block — the order still gets saved as taken in the DB, but the taker never receives the message and nobody is notified that it failed.
Could it be that this issue isn't actually caused by the MarkdownV2 problem, but by this other failure mode instead? If you have logs or a screenshot from when you saw the error, that would help a lot narrowing it down.
Anyway, happy to help dig into this further if anything else comes up!
mgatmiri commentedon Aug 5, 2026
Thank u fot looking into the issue. Honestly i'm a non-techy user just trying to report ehat my selliw persian users have been experiencing fir the couple months ago. Here's one example:

Here, the taker took the above sell order a couple of times while lang was set to farsi, and the bot doesn't respond, then sends a message that says "no invoice was sent ..."
Then, when lang is set to eng by the taker, problem is solved.
Screenshot messages Date: 5 Aug 2026 - 14:55 (UTC+3:30)
ToRyVand commentedon Aug 10, 2026
I'd like to take this one. I traced it on current
main:beginTakeSellMessagealready wraps its sends in a try/catch, but the catch only logs — so when the MarkdownV2 send ofyou_took_someone_orderthrows, the taker message is silently lost, exactly as described.This complements the merged #872 (which escaped reserved chars in the Farsi locale) rather than replacing it: escaping is fragile (any new unescaped char reintroduces the bug), whereas the proposed retry-without-
parse_modefallback guarantees the taker still receives the message even if a translation slips through. Same resilience principle I'm applying in #595 (a send failure to one party shouldn't drop the message).I'll wrap just the
you_took_someone_ordersend with the MarkdownV2→plain fallback and add a regression test. Could you assign it to me?grunch commentedon Aug 10, 2026
@ToRyVand go ahead 👍🏽