Еще бы разобраться, как обрабатывается нажатие «Разрешить» на границе тайм-аута? Обработчик кнопки и ветка тайм-аута могут почти одновременно попытаться закрыть один запрос. И как в реестре выбирается единственный результат и что получает пользователь при позднем нажатии? Ведь одного удаления кнопок для этого недостаточно: событие нажатия уже могло поступить в обработку.
Автору спасибо:) Единственное — вариант с file удобен для файла, который действительно поставляется вместе со скриптом. А для конфигурации конкретного сервера я бы предусмотрел явный путь через аргумент запуска или переменную окружения. Тогда один и тот же код можно запускать с разными настройками, не складывая их в каталог приложения. Это упрощает и проверку сервиса с тестовым конфигом.
Наверное, включал бы уточнение к позднему ответу в исходную консультацию, в пределах оговорённого числа раундов. Иначе клиент отправит вопрос вовремя, дождётся ответа, а возможность переспросить уже закончилась.
Можно дать на такое уточнение отдельный срок, например до конца следующего рабочего дня после ответа эксперта. При этом оно должно относиться к исходной задаче: новую тему оформляем отдельно. В бэке тогда нужны две границы: до какого момента принимаются новые вопросы и до какого уточнения к конкретному ответу. Так поздний ответ не продлевает всю консультацию, но оставляет клиенту возможность закончить начатый разбор.
К фикстуре as_user дополнил бы: если другая фикстура уже подменила get_current_user, очистка через pop удалит и эту исходную подмену. Для приведённого примера это нормально, но при нескольких уровнях фикстур лучше восстанавливать прежнее значение. Здесь можно воспользоваться встроенной фикстурой monkeypatch: передать её в as_user, а внутри set_user вызвать monkeypatch.setitem(app.dependency_overrides, get_current_user, lambda: {"name": name}). Ручной pop тогда не нужен: после теста pytest вернёт прежнюю подмену, а если её не было — удалит добавленный ключ.
Для теста этой гонки я бы задерживал ответ заглушки Telegram. Две точки синхронизации: «запрос на отправку принят» и «можно вернуть успешный ответ». Между ними тест отменяет старую задачу, дожидается подтверждения отмены и запускает новую. Затем разрешает завершиться старой отправке. В одном тестовом event loop это можно организовать через два asyncio.Event, чтобы не подбирать задержки через sleep. Проверял бы ещё, что поздний ответ остаётся привязан к старому task_id: не переводит новую задачу в состояние «выполнена» и не перезаписывает ссылку на её результат. Даже при первом, более мягком контракте отмены здесь можно получить отдельную ошибку.
Еще бы разобраться, как обрабатывается нажатие «Разрешить» на границе тайм-аута? Обработчик кнопки и ветка тайм-аута могут почти одновременно попытаться закрыть один запрос. И как в реестре выбирается единственный результат и что получает пользователь при позднем нажатии? Ведь одного удаления кнопок для этого недостаточно: событие нажатия уже могло поступить в обработку.
Автору спасибо:) Единственное — вариант с
fileудобен для файла, который действительно поставляется вместе со скриптом. А для конфигурации конкретного сервера я бы предусмотрел явный путь через аргумент запуска или переменную окружения. Тогда один и тот же код можно запускать с разными настройками, не складывая их в каталог приложения. Это упрощает и проверку сервиса с тестовым конфигом.Наверное, включал бы уточнение к позднему ответу в исходную консультацию, в пределах оговорённого числа раундов. Иначе клиент отправит вопрос вовремя, дождётся ответа, а возможность переспросить уже закончилась.
Можно дать на такое уточнение отдельный срок, например до конца следующего рабочего дня после ответа эксперта. При этом оно должно относиться к исходной задаче: новую тему оформляем отдельно. В бэке тогда нужны две границы: до какого момента принимаются новые вопросы и до какого уточнения к конкретному ответу. Так поздний ответ не продлевает всю консультацию, но оставляет клиенту возможность закончить начатый разбор.
Как будто бы то шо да
К фикстуре
as_userдополнил бы: если другая фикстура уже подменилаget_current_user, очистка черезpopудалит и эту исходную подмену. Для приведённого примера это нормально, но при нескольких уровнях фикстур лучше восстанавливать прежнее значение.Здесь можно воспользоваться встроенной фикстурой
monkeypatch: передать её вas_user, а внутриset_userвызватьmonkeypatch.setitem(app.dependency_overrides, get_current_user, lambda: {"name": name}). Ручнойpopтогда не нужен: после теста pytest вернёт прежнюю подмену, а если её не было — удалит добавленный ключ.Для теста этой гонки я бы задерживал ответ заглушки Telegram. Две точки синхронизации: «запрос на отправку принят» и «можно вернуть успешный ответ». Между ними тест отменяет старую задачу, дожидается подтверждения отмены и запускает новую. Затем разрешает завершиться старой отправке. В одном тестовом event loop это можно организовать через два
asyncio.Event, чтобы не подбирать задержки черезsleep.Проверял бы ещё, что поздний ответ остаётся привязан к старому
task_id: не переводит новую задачу в состояние «выполнена» и не перезаписывает ссылку на её результат. Даже при первом, более мягком контракте отмены здесь можно получить отдельную ошибку.