Return to a previous conversation state after a already handled update message being edited #5111

Returning a state from a fallback changes the state for the next update; it does not send the current update back through handler selection. Re-queueing the same update is therefore the wrong level of abstraction here.

There are two issues in the example:

1. State selection and callback execution happen before PTB applies the callback's returned state. PTB calls the selected handler, waits for its result, and only then calls _update_state: source.
2. Your state filter explicitly excludes EDITED_MESSAGE, so the queued copy cannot match those state handlers anyway.

For this use case, separate “validate/store this field” from “advance the conversation”. Then the edit fallback can call the same field logic directly while leaving the user's current conversation state unchanged:

async def save_company(text: str, context: ContextTypes.DEFAULT_TYPE) -> None:
    # validate text and update the existing database row
    ...


async def company(
    update: Update, context: ContextTypes.DEFAULT_TYPE
) -> int:
    message = update.effective_message
    if message is None or message.text is None:
        return COMPANY

    await save_company(message.text, context)
    context.bot_data["message_map"][(message.chat_id, message.message_id)] = COMPANY
    return PERIOD


EDIT_HANDLERS = {
    COMPANY: save_company,
    PERIOD: save_period,
    COST: save_cost,
}


async def handle_edited_message(
    update: Update, context: ContextTypes.DEFAULT_TYPE
) -> None:
    message = update.edited_message
    if message is None or message.text is None:
        return None

    state = context.bot_data["message_map"].get(
        (message.chat_id, message.message_id)
    )
    save = EDIT_HANDLERS.get(state)
    if save is not None:
        await save(message.text, context)

    # None means: keep the current ConversationHandler state.
    return None

Use (chat_id, message_id) as the map key; message_id alone is only unique inside one chat. For callbacks that should handle both original and edited messages, prefer update.effective_message over update.message.

Also avoid feeding the same Update back into application.update_queue: it duplicates one Telegram update and makes loops/order bugs possible. ConversationHandler relies on updates being processed sequentially, so keep concurrent_updates(False): source.

If you intentionally want the user to return to that old state and provide a new message, simply return state from the fallback and do not re-queue the edited update.