Тайм-аут запроса Django для некоторых статических файлов при запуске теста manage.py package.to.unit.test - PullRequest
Новая
       16

Тайм-аут запроса Django для некоторых статических файлов при запуске теста manage.py package.to.unit.test

3 голосов
/ 30 октября 2019

Контекст :

Мы запускаем Cypress-тесты, которые используют экземпляры нашего приложения, которые начали использовать manage.py test package.test.suite. Все тестовые устройства и окружение настроены с использованием класса, расширенного с django.contrib.staticfiles.testing.StaticLiveServerTestCase. Модульный тест / метод добавлен в расширенный класс, который вызывает Cypress в качестве подпроцесса для запуска тестов и утверждает код завершения подпроцесса.

Версии:

  • Python:3.6.8
  • Джанго: 2.2.3
  • macOS: Мохаве 10.14.6

Проблема :

Это работало хорошо до вчерашнего дня, когда я обновил Cypress через npm. Теперь, когда я запускаю сервер, используя manage.py test some.test.suite, сервер не сможет обслуживать все статические ресурсы, запрошенные браузером. В частности, он почти всегда не может обслуживать некоторые шрифты .woff и случайный файл javascript / css или два. Остальные файлы обслуживаются, кроме тех 5 или 6, на которые браузер никогда не получает ответ. В конце концов я получу ошибку ConnectionResetError: [Errno 54] Connection reset by peer (трассировка стека ниже) в терминале. Кроме того, если я включу кэш в своем браузере и попытаюсь выполнить несколько обновлений, все будет работать нормально, как будто существует ограничение на количество файлов, которые можно обслуживать одновременно, и как только некоторые файлы кэшируются в браузере, количество запрошенныхколичество файлов падает ниже этого предела.

Однако когда я делаю python manage.py runserver, у меня вообще не возникает этой проблемы с включенным или без кэширования.

Трассировка стека: 

----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 52655)
Traceback (most recent call last):
  File "/Users/myuser/.pyenv/versions/3.6.8/lib/python3.6/socketserver.py", line 320, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/Users/myuser/.pyenv/versions/3.6.8/lib/python3.6/socketserver.py", line 351, in process_request
    self.finish_request(request, client_address)
  File "/Users/myuser/.pyenv/versions/3.6.8/lib/python3.6/socketserver.py", line 364, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/Users/myuser/.pyenv/versions/3.6.8/lib/python3.6/socketserver.py", line 724, in __init__
    self.handle()
  File "/Users/myuser/Path/To/Project/venv/lib/python3.6/site-packages/django/core/servers/basehttp.py", line 171, in handle
    self.handle_one_request()
  File "/Users/myuser/Path/To/Project/venv/lib/python3.6/site-packages/django/core/servers/basehttp.py", line 179, in handle_one_request
    self.raw_requestline = self.rfile.readline(65537)
  File "/Users/myuser/.pyenv/versions/3.6.8/lib/python3.6/socket.py", line 586, in readinto
    return self._sock.recv_into(b)
ConnectionResetError: [Errno 54] Connection reset by peer
----------------------------------------

Дополнительные примечания / замечания

  • Проблема также возникает, когда я запускаю тесты без головы.

  • При установке Cypress возникла заминка, которая потребовала от меня переустановки Electron и Cypress, очистки кэша npm и удаления папки кэша Cypress.

  • Также странно, что проблема, похоже, связана ссреда Python, а не сам Cypress, поскольку доступ к веб-серверу через мой браузер, а не Cypress, приводит к тому же самому поведению;поэтому, возможно, Cypress - просто красная сельдь, и какая-то общая зависимость была изменена / обновлена ​​в процессе.

  • Если я попытаюсь получить прямой доступ к одному из файлов, который не обслуживаетсяво время запроса, который отображается как «ожидающий» на вкладке сети инструментов разработчика Chrome, непосредственно через вторую вкладку он будет выполнен успешно (но иногда будет отставать на несколько секунд).

  • После закрытия тестового сервера и попытки его запуска снова я получу ошибку [OSError: [Errno 48] Address already in use] в течение одной или двух минут. Ранее сервер отказывался от адреса / порта сразу после закрытия (или я предполагаю, что так, поскольку я никогда не видел этого раньше и быстро закрывал и повторно запускал тесты, чтобы проверить изменения фикстур в прошлом).

Вещи, которые я пробовал :

  • Восстановление моего virtualenv с нуля
  • Копирование моей старой папки venv из резервной копии Time Machineсо времени, когда все заработало
  • Возвращение версии Cypress обратно к тому, что было до проблемы
  • Просмотр тайм-аутов и ограничений на использование manage.py test против manage.py runserver (Didn 'ничего не найти).
  • Переключение режима отладки и включение / выключение профилирования.
  • Переключение между Chrome и Chromium в Cypress
  • Создание новых сред с различными версиями Python (3.6.5, 3.6.7 и 3.6.8)
  • Переключение Django обратно на 2.2.2 с 2.2.3

Любая помощь приветствуется!

Обновление

Заглядывая в эту гущупохоже, запросы на файлы, которые не получают ответа, никогда не поступают в WSGIHandler из уровня Socket (или даже если они попадают в уровень сокетов, я бы предположил, что они это делают).

Обновление 2

Я вижу то же поведение с manage.py runserver, если я включаю переключатель --nothreading. У меня был сотрудник, который дал ему тест, и он действительно видел такое же поведение с manage.py runserver --nothreading, но manage.py test test.to.run все еще работал нормально для него.

Кроме того, удаление ссылок на шрифты из css / templates просто приводит к другому набору из 5 файлов, которые не обслуживаются.

...