python-telegram-bot / python-telegram-bot

We have made you a wrapper you can't refuse
https://python-telegram-bot.org
GNU General Public License v3.0
26.3k stars 5.34k forks source link

Filters.regex fails on non-text messages #1115

Closed Thorbijoern closed 6 years ago

Thorbijoern commented 6 years ago

Steps to reproduce

  1. given a handler like the following: def msg(bot, update): answer = random.choice(bot_misc.ANSWERS) update.message.reply_text(answer) updater.dispatcher.add_handler(MessageHandler(Filters.regex('Hi'), msg))

  2. send the bot some kind of media (like a sticker, an image or a voice-message)

  3. error (success)

Expected behaviour

I usually expect a regex filter to imply Filters.text (that the message is text), because you can only regex over text...

Actual behaviour

the regex filter fails with the following error when it tries to process the update: 2018-05-21 18:15:43,279 - telegram.ext.dispatcher - ERROR - An uncaught error was raised while processing the update Traceback (most recent call last): File "/home/thorbijoern/env/ptb/lib/python3.6/site-packages/telegram/ext/dispatcher.py", line 278, in process_update for handler in (x for x in self.handlers[group] if x.check_update(update)): File "/home/thorbijoern/env/ptb/lib/python3.6/site-packages/telegram/ext/dispatcher.py", line 278, in <genexpr> for handler in (x for x in self.handlers[group] if x.check_update(update)): File "/home/thorbijoern/env/ptb/lib/python3.6/site-packages/telegram/ext/messagehandler.py", line 152, in check_update res = self.filters(message) File "/home/thorbijoern/env/ptb/lib/python3.6/site-packages/telegram/ext/filters.py", line 65, in __call__ return self.filter(message) File "/home/thorbijoern/env/ptb/lib/python3.6/site-packages/telegram/ext/filters.py", line 201, in filter return bool(self.pattern.search(message.text)) TypeError: expected string or bytes-like object

workaround

a workaround would be just using (Filters.text & Filters.regex('foo')).

Eldinnie commented 6 years ago

Although there is a small addition to the expected behavior (it should also work on captions, not only text), it's bad behavior that it does not check this. Thanks for the report.