Several ideas for changes and/or additions have been gathered in the v14 project, mentioned in the user group or issues or dwelled in the back of my head. So I'm writing this issue to keep track of them better.

The following list of ideas should be discussed before release of v14 because at least some of them are easier to implement if we do them non-backwards compatible. I'd like to emphasize that most of these are very rough first thoughts and I'm fully aware that we may scrape many of them.

Related:#2802

• MakeCH.fallbacks optional. I've seen a lot of people (including me) setting at to an empty list for some use cases … Poolitzer already expressed support for this idea
• ConverstanionHandler + run_async: Problem is that we can't persist futures/promises. But we should be able to guarantee that all futures are done on (clean) shutdown. One could add something likeBasePersistence.resolve_conversation_promises that persistence classes can call before flushing on shutdown. This already get's handled on v20
• [FEATURE] ConversationHandler: Allow special handlers/callbacks for entering states #2390 (closed just for better overview, not actually implemented)
• add a "prefallbacks" list, i.e. the state-handlers only trigger, if the "prefallback" handlers don't trigger. The current alternative is to add those handlers to thefallbacks list, which requires to make all state handlers ignore updates that should be handled by thefallbacks. see alsoAdded impementation of "prefallbacks" list. #2764#2764; Implemented "prefallbacks" feature #2960
• Includeentry_points,fallbacks (and eventual "prefallbacks") into thestates dict. We already have special states forTIMEOUT andWAITING, so I think it would make the interface cleaner if we used special states(PRE)FALLBACK andEND as keys for these lists rather than making them standalone kwargs of__init__
• Think about "conversation related data", e.g.context.conversation_data. It should be an object unique per conversation key andConversationHandler instance. It may even be automatically deleted when the conversation ends . See also[FEATURE] Have per-conversation data (or at least an identifier) in ConversationHandler #4136
• Rethink which parts ofConversationHandler we consider public.
  • e.g. theconversations is currently public, although undocumented and basically part of the internals. If we make it private, we can rework the setters ofpersistence andconversations to something likeget_persisted_data(persistence) orinitialize_persistence(persistence)
  • We also rather regularly get questions like "how do I access the current state of the conversation" and "how do I check if a user has an active conversation". Making the logic of how the keys are build and howconversations works publicmay help with some of these and also with the abovecontext.conversation_data
  • One could take this one step further and let the user customize how the key is generated. This could be useful e.g. in situations where one wants to handle 3rd-party updates (e.g. login into an external service) within the conversation, which are not of typetelegram.Update. see alsoConversationHandler do not support per_message_thread_id conversations #4768 for a request to make the CH state per message thread ID
• think aboutconversation_timeout:
  • Is it worth to allow timeout handlers to put the conversation in a non-end state?
  • it it worth to try & allow a different timeout duration per state?
  • Can we make them work for nested conversations?
  • Can we ensure that the timeout jobs can be persisted?
• [FEATURE] class-based nested conversations #2827 to make CH be based more on a class-like structure
• nested conversations:
  • Check behavior of theWATING state, especially with nested conversations
  • Check behavior of async handlers with nested conversations
  • Once a child conversation has started one may want the next update to be processed exclusively by that child conversation, even if it's not the first handler in the state. Maybe this can be made possible. See alsohttps://stackoverflow.com/questions/78143788
• Think about a mechanism to lazy-load persisted conversation states to allow to reduce load on startup. would be especially useful for stateless server designs. Seehere for some initial discussion. Note also that in stateless setups, arefresh_conversation_data would be useful, see[QUESTION] How to work with persistent conversation data across multiple processes #4452.
• When the conversation has ended, passCH.END topersistence.update_conversation instead ofNone
• We currently issue a warning forper_message=True, per_chat=False - this is not necessarily valid in caseinline_message_ids are used
• entry_points should be checkedafter the states are checked - that way, state handlers may trigger before anyentry_points trigger viaallow_reentry. Seehttps://t.me/pythontelegrambotgroup/606782?thread=606781 for a question on that. Edit: On second thought, theallow_reentry may not be needed at all - the user can just repeat theentry_points in thefallbacks. If "prefallbacks" (see above) are added, that even allows the user to customize which of state handlers andentry_points are checked first
• A commonly requested feature is to track a "conversation" between two (or more) users who each chat with the bot in the respective private chat. If we could make something like this feasible, that would be awesome.
• discuss possibility to make job timeouts persistent:[FEATURE] Persist timeouts of ConversationHandler #3522
• Improve type hinting where possible - seeSub-Optiomal type hints inConversationHandler #3665 (closed only to track this here)
• Errors in the timeout state should be handled like errors in handlers, not like errors in jobs - seehttps://t.me/pythontelegrambotgroup/675226
• In case built-in states are used, they should either not be easy to reproduce or we should warn if the user tries to use them manually. See[FEATURE] warn ifConversationHandler.states has a key -1 #3834
• Rethink if we want to allow for some error handling on CH or even state level. SeeFrom error state to other state on a Conversational bot #2277 for some discussion