Bot.send_message зависает при parse_mode=None

[Stilver]

Добрый день!

Обнаружили проблему в работе библиотеки. При передаче в метод send_message параметра parse_mode=None отправка сообщения намертво зависает на data = await future в trueconf.methods.base.TrueConfMethod.__call__. Воспроизвести достаточно просто:

import asyncio
from trueconf import Bot

async def main():
    bot = Bot.from_credentials(
        username="login",
        password="password",
        server="server",
        dispatcher=None
    )
    await bot.start()
    await bot.send_message(chat_id="chat_id", text="hi", parse_mode=None)
    print('Это сообщение мы не увидим')


asyncio.run(main())

В типизации к параметру в send_message конечно указано, что ожидается только str, однако в библиотеке нет никакой реакции на то, что был передан некорректный параметр, а исполняемый код бесконечно ожидает какой-то реакции от сервера.

Прошу посмотреть:

1. Можно ли на уровне библиотеки решить проблему с бесконечным зависанием? Причем не только с точки зрения проверки типизации, но и какой-то механизм защиты от бесконечного ожидания в целом с логированием потенциальной причины ее возникновения.
2. Можно ли на уровне сервера настроить какую-то ответную реакцию (если до него сообщение все-таки доходит), которая могла бы помочь в отладке аналогичных проблем?

[tb-sourse]

@Stilver

Таймаут добавить не сложно, но вы же передали None вместо str. Нужно в библиотеку добавлять валидацию входящих и исходящих запросов, для этого нужен переход на другую зависимость. Вместо mashumaro использовать pydantic, но он медленее mashumaro, в том числе из-за валидации. Есть вариант перейти на mgspec, он быстрее, но строже.

В общем нужно провести оценки по трудозатратам и правильному выбору библиотеки.

[Stilver]

Прецеденты с труконф подсвечивают два момента:

1. Доверие к серверу в контексте валидации параметров подорвано. Отсутствие реакции от сервера на передачу некорректного параметра потребовало от нас потратить очень много времени на поиск реальной причины
2. Либо дело не только в сервере, но и в библиотеке, т.к. под капотом могут происходить явные/неявные преобразования невалидных параметров, которые сервером могут быть восприняты как валидные.

Отмечу, что при версии либы 1.1.10 и версии сервера 5.5.2 выполнение send_message с parse_mode=None не приводило к зависанию при таком простом примере, отчего было совсем не очевидно, что проблема в новых версиях именно с parse_mode. Дифф по версиям либы тоже никак не намекал на эту проблему. Поэтому видится, что вопрос валидации параметров стоит острее, чем скорость работы.

[tb-sourse]

@Stilver

1. Серверная валидация в работе, в планах на 5.5.5.
2. Библиотека на данных момент не делает неявных преобразований.

Вопрос в том, почему вы передаете None, когда требуется str, для меня остается открытым. Разве IDE не уведомляло о неверном типе? Тип по умолчанию для parse_mode == ParseMode.TEXT, если не хотите чтобы форматирование применялось. Вы можете явно не передавать parse_mode, будет по умолчанию plain text.

[tb-sourse]

Добавлен timeout в 10 сек для Future, которые ожидают ответ от сервера 1524c92

[Stilver]

IDE не предупреждает, если выбор типа происходит в отдельной функции, а результат записывается в переменные, которые и передаются в send_message. Причин для подобных ситуаций достаточно. Python к сожалению такое позволяет.