I tested out the current release 20.0a0. Every non-blocking callback inside state or fallback that returns None has that issue not only entry points I think. Maybe that is already fixed somewhere else. Currently, when I am returning None in any state I get the PendingState... error.

@CedricFauth thanks for the info! I've pushed more changes that should address that. Could you check if those fix the problems for you? You can install from this branch via pip install git+https://github.com/python-telegram-bot/python-telegram-bot.git@ch-entry-point-bug.

@Bibo-Joshi Yes but no :/ You fixed my previous problem. Returning None now works inside the conversation handler but a new problem occurred:
I am unable to leave a conversation (return ConversationHandler.END). The next time I send a message to the bot (after ending a conversation) it says: Selecting conversation (..., ...) with state -1 (which is the END state so the bot should have left the conversation before but does not). This ends in my fallback handler getting called every time I send a message. The user is not able to do anything because the conversation stays in state -1 forever.
This is only the case when using ConversationHandler(block=False) and the current branch ch-enrty-point-bug. In the pre-release it never happened.
Hope I could help you find the problem.

Yeah, I should have properly run the tests before pushing 🤦‍♂️ hopefully it's now better :)

Seems to work now, thanks!

State is correctly switched to GENDER though.

Just to double check: your observation is only about error prints & not about wrong behavior right?

The difference is the heading of the traceback: The first (triggered by /start) will say No error handlers are registered, logging exception.. If you have a custom error handler, this one won't show (unless your error handler explicitly logs it again).
The second one (striggered by the next update) will say Task function raised exception. Falling back to old state None, which is logged by PendingState.resolve(). IMO those two long entries serve different purposes: The first informing you about an error in the callback & the second one about what's going on state-wise in the ConversationHandler. the traceback being printed twice may surely be seen as a bit overly verbose in the default case, though I guess it's not really harmful either.

Just to double check: your observation is only about error prints & not about wrong behavior right?

Yes. It confused me, thinking it was running the start callback again somehow, and will confuse others too, eventually

But why should we re-print the error message when it's already printed/forwarded to error handler the first time? Maybe we should move the "Task function raised exception. Falling back to old state %s" to when the error actually happens the first time (is this possible to do?)