Hello.
In my bot, there is a nested conversation handler:

nested_registration_handler = ConversationHandler(
    entry_points=[
        CallbackQueryHandler(handle_registration_consent_agree, pattern=utils.generate_pattern_for_enum(keyboards.AgreeDisagree)),
    ],
    states={
        # Some states skipped
        # ...
    },
    fallbacks=[
        CommandHandler("cancel", handle_nested_registration_cancel),
    ],
    map_to_parent={
        ConversationHandler.END: ConversationHandler.END,
    }
)

# Main account menu handler
account_handler = ConversationHandler(
    entry_points=[
        CommandHandler("account", handle_enter_account_menu)
    ],
    states={
        # some states skipped
        # ...
        ACCOUNT_MENU_START_REGISTRATION: [
            nested_registration_handler,
        ],
    },
    fallbacks=[
        CommandHandler("cancel", handle_account_menu_cancel),
    ],
)

For each of the handlers, I create a separate ChatHelper object that performs various auxiliary tasks and is stored in user_data. When each handler ends, I want to clear its ChatHelper. Also, when the nested_registration_handler is cancelled, I want to cancel the account_handler. So in the case of processing the /cancel command both ChatHelpers should be removed. At the same time, I want each handler to manage its own ChatHelper—to reduce confusion. I’ve encountered a problem where I can’t come up with a simple way to do this. For example, I’m currently trying the following solution for handling the /cancel command:

nested_registration_handler = ConversationHandler(
    entry_points=[
        CallbackQueryHandler(handle_registration_consent_agree, pattern=utils.generate_pattern_for_enum(keyboards.AgreeDisagree)),
    ],
    states={
        # Some states skipped
        # ...
    },
    fallbacks=[
        CommandHandler("cancel", handle_nested_registration_cancel),
    ],
    map_to_parent={
        ConversationHandler.END: ConversationHandler.END,
        9999: 9999,
    }
)

# Main account menu handler
account_handler = ConversationHandler(
    entry_points=[
        CommandHandler("account", handle_enter_account_menu)
    ],
    states={
        # some states skipped
        # ...
        ACCOUNT_MENU_START_REGISTRATION: [
            nested_registration_handler,
        ],
        9999: [
            CommandHandler("cancel", handle_account_menu_cancel),    
        ]
    },
    fallbacks=[
        CommandHandler("cancel", handle_account_menu_cancel),
    ],
)

That is, a special state 9999 was added. The nested_registration_handler intercepts the /cancel command, processes it, and returns control to the parent account_handler, transitioning it to state 9999. To ensure that handle_account_menu_cancel is triggered immediately, I have to do await context.update_queue.put(update) in the nested_registration_handler. And here, actually, are my questions:

1. In theory, such a construction won't work if there is more than one update in the queue, because then the next update in the queue for the account_handler may not necessarily be the current update with the /cancel command. So, how can I force the account_handler to execute handle_account_menu_cancel in the current situation?

2. General question. How does the update processing loop actually work in PTB? Let's say the bot uses polling. It requested updates from Telegram servers — let's say it received 10 updates from 10 different users. Assume the same ConversationHandler is used to process all these updates. Then the first update will switch the handler to a state where the remaining updates cannot be processed until the handler returns to its initial state. Does this mean each update will wait for the previous ones to be processed?