Опишите ошибку
tests/http.os → ТестДолженПроверитьПолучениеStreamEvent периодически падает на Windows-агенте:
Значение <1046> больше или равно, чем <600>, а ожидалось меньше
-> ТестДолженПроверитьПолучениеStreamEvent (482), tests\http.os
Тест поднимает веб-сервер в фоновом задании и проверяет, что заголовки ответа приходят раньше, чем обработчик досчитает до конца. Обе завязки — на стенные часы, без единой попытки повтора:
МенеджерФоновыхЗаданий.Выполнить(ЭтотОбъект, "Вебсервер");
...
// Подождем пока поднимится сервер
Приостановить(1000);
Старт = ТекущаяУниверсальнаяДатаВМиллисекундах();
Ответ = Соединение.ВызватьHTTPМетод("GET", Запрос);
Прошло = ТекущаяУниверсальнаяДатаВМиллисекундах() - Старт;
ютест.ПроверитьМеньше(Прошло, 600);Готовность сервера ждётся фиксированной секундой. Если на нагруженном агенте старт фонового задания плюс подъём Kestrel в неё не уложились, клиентский запрос блокируется до появления слушателя, и это время целиком попадает в Прошло. Полученные 1046 мс на такую картину ложатся.
Воспроизведение ошибки
Плавающее, зависит от загруженности агента. На Linux не воспроизводится.
Ожидаемое поведение
Тест меряет латентность заголовков, а не сумму латентности и остатка времени старта сервера, и не зависит от того, уложился ли старт в заранее заданную константу.
Окружение
- ОС: Windows (Jenkins-агент). На Linux стабильно зелёный.
- Версия:
develop
Дополнительная информация
Замер на Linux показывает примерно десятикратный запас до порога — заголовки приходят за 46–75 мс при пороге 600. То есть сам порог не жадный, проблема именно в ожидании старта.
Возможное решение — заменить Приостановить(1000) на опрос готовности: цикл коротких попыток подключения с общим дедлайном, и только после успешного подключения начинать замер. Тогда медленный старт агента растянет фазу ожидания, а не попадёт в измеряемую величину.
Замечено в сборках PR #1725. Там же на Windows в разных сборках падали ещё два таймингованных теста из других подсистем — console.os → ТестДолжен_ПроверитьТаймаутЧтенияСтандартногоПотокаВвода и process.os → ТестДолжен_ПрочитатьВыводOscriptПострочно (последний разобран отдельно в #1726). Возможно, имеет смысл посмотреть на группу таймингованных тестов целиком.
Опишите ошибку
tests/http.os→ТестДолженПроверитьПолучениеStreamEventпериодически падает на Windows-агенте:Тест поднимает веб-сервер в фоновом задании и проверяет, что заголовки ответа приходят раньше, чем обработчик досчитает до конца. Обе завязки — на стенные часы, без единой попытки повтора:
Готовность сервера ждётся фиксированной секундой. Если на нагруженном агенте старт фонового задания плюс подъём Kestrel в неё не уложились, клиентский запрос блокируется до появления слушателя, и это время целиком попадает в
Прошло. Полученные 1046 мс на такую картину ложатся.Воспроизведение ошибки
Плавающее, зависит от загруженности агента. На Linux не воспроизводится.
Ожидаемое поведение
Тест меряет латентность заголовков, а не сумму латентности и остатка времени старта сервера, и не зависит от того, уложился ли старт в заранее заданную константу.
Окружение
developДополнительная информация
Замер на Linux показывает примерно десятикратный запас до порога — заголовки приходят за 46–75 мс при пороге 600. То есть сам порог не жадный, проблема именно в ожидании старта.
Возможное решение — заменить
Приостановить(1000)на опрос готовности: цикл коротких попыток подключения с общим дедлайном, и только после успешного подключения начинать замер. Тогда медленный старт агента растянет фазу ожидания, а не попадёт в измеряемую величину.Замечено в сборках PR #1725. Там же на Windows в разных сборках падали ещё два таймингованных теста из других подсистем —
console.os→ТестДолжен_ПроверитьТаймаутЧтенияСтандартногоПотокаВводаиprocess.os→ТестДолжен_ПрочитатьВыводOscriptПострочно(последний разобран отдельно в #1726). Возможно, имеет смысл посмотреть на группу таймингованных тестов целиком.