Skip to content

[QUESTION] Documentation on #1678 / #1680 #1900

@niklasbogensperger

Description

@niklasbogensperger

Issue I am facing

My question is about issue #1678 and its corresponding commit #1680.
I have not worked on my bot since October, so I went through the transition guide to version 12 again in case I missed something in the meantime. After starting my bot again for the first time and playing around with it, I discovered that the various "/cancel" fallback states in my ConversationHandlers were broken, although they previously worked. During my attempts at fixing this, I went through the documentation on the Filters module, the ConversationHandler, and the MessageHandler.
Nothing seemed to get my fallback state to kick in, until I discovered #1678. As can be seen in my code, the bot is supposed to accept any text as a response except a certain command, which triggers the fallback state.
In essence, I now need to explicitly check if the received message is text and not a command (which was previously implied by just the text filter).
I do not know whether my solution was optimal to begin with, but at least everything appeared to be working before this change.

If this is all intended behavior, I would suggest updating the docs in at least one of these places:

  • In the tutorial "Extensions – Your first Bot" at the very end, the note about the "unkown command" handler should include a warning that if any catch-all command handler with a text filter is added before it, it will not do anything. In fact, the last two MessageHandlers in my code were exactly like this because I followed this tutorial when I started. I discovered that the behavior of these two was also broken (I want to give two different replies depending on whether someone only entered text - which does nothing aside from during the conversations - or an unknown command).
  • The docs for telegram.ext.filters should make a mention in the Filters.text section about also matching leading commands (only in special circumstances like mine?).
  • The transition guide to version 12 could make a mention about this in the section on combining filters (as the fix for my problem uses this new behavior).

Related part of my old code

def main():
    #### ...
    conversation_handler_start = ConversationHandler(
        entry_points=[CommandHandler("start", start)],
        states={
            START_NAME_STATE: [MessageHandler(Filters.text, start_name)],
            START_MESSAGE_STATE: [MessageHandler(Filters.text, start_message)]
        },
        fallbacks=[CommandHandler("startcancel", startcancel)]
    )
    dispatcher.add_handler(conversation_handler_start)
    #### ...
    # --- Catch-all commands for unknown inputs:
    dispatcher.add_handler(MessageHandler(Filters.text, text))
    # The "unknown" handler needs to be added last because it would override any handlers added afterwards
    dispatcher.add_handler(MessageHandler(Filters.command, unknown))

Fixed new code

def main():
    #### ...
    conversation_handler_start = ConversationHandler(
        entry_points=[CommandHandler("start", start)],
        states={
            START_NAME_STATE: [MessageHandler(Filters.text & (~ Filters.command), start_name)],
            START_MESSAGE_STATE: [MessageHandler(Filters.text & (~ Filters.command), start_message)]
        },
        fallbacks=[CommandHandler("startcancel", startcancel)]
    )
    dispatcher.add_handler(conversation_handler_start)
    #### ...
    # --- Catch-all commands for unknown inputs:
    dispatcher.add_handler(MessageHandler(Filters.text & (~ Filters.command), text))
    # The "unknown" handler needs to be added last because it would override any handlers added afterwards
    dispatcher.add_handler(MessageHandler(Filters.command, unknown))

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions