Я только что прибыл сюда сам после обновления с 4.2 до 5.1 и сейчас 5.2, и я вижу то же самое в своем тестировании, когда я замораживаю тест в середине запроса с binding.pry, я получаюсообщение Requests did not finish in 60 seconds.Какая замечательная история, перейдите к концу для tl; dr (возможно, я понял это.)
Теперь я обновил все драгоценные камни постепенно, чтобы я мог сохранить способность делить пополам и наблюдать источникинтересных изменений, как этот.Я только заметил этот новый 60-секундный тайм-аут после перехода с chromedriver-helper, который сообщил, что он устарел к новому webdrivers гему, который вступает во владение, но это, похоже, не связано, поскольку я искал веб-драйверы для любого тайм-аута или значения 60 секунди обнаружил только ссылки на несвязанный запрос на извлечение № 60 (исправляет проблему № 59).
Я проверил каталог своего источника gem на наличие этого сообщения Requests did not finish in 60 seconds и обнаружил, что на самом деле это не старая версияКапибара, но она была поднята из версий, начиная с версии не ниже 3.9.0, и в самой последней версии 3.24.0 в lib/capybara/server.rb.
Используемый там объект есть Таймер, который вы можете найтиинтерфейс к нему здесь, в помощнике:
https://github.com/teamcapybara/capybara/blob/320ee96bb8f63ac9055f7522961a1e1cf8078a8a/lib/capybara/helpers.rb#L79
Это конкретное сообщение возникает из метода wait_for_pending_requests, который передает хард-60 в именованный параметр :expire_in,затем после отправляет любые ошибки, которые были обнаружены в потоке сервера.Это означает, что время не настраивается, вероятно, 60 секунд - это разумный промежуток времени для ожидания выполнения веб-запроса, хотя это немного неудобно для моего теста.
Этот метод вызывается только в одномместо, reset!, которое вы можете найти здесь, в capybara/session.rb: https://github.com/teamcapybara/capybara/blob/320ee96bb8f63ac9055f7522961a1e1cf8078a8a/lib/capybara/session.rb#L126
Сброс!Метод интересный, который поставляется с некоторой документацией о том, как он используется.@server&.wait_for_pending_requests похоже, что он может вызвать wait_for_pending_requests, если в запросе есть активный поток сервера, а затем повысить_сервер_еррор!который действует аналогично, только если @server&.error является правдивым.
Теперь мы находим этот сброс!поставляется с двумя псевдонимами, это сообщение reset! принимается всякий раз, когда Capybara вызывает cleanup! или reset_session!.На данный момент мы, вероятно, можем понять, что произошло, но это все еще немного загадочно, когда я использую тестирование chromedriver-helper и селен в течение нескольких лет, но никогда не вспоминаю, что видел этот 60-секундный тайм-аут раньше.Я не решаюсь указать пальцем на вебдрайвера, но у меня нет других ответов, почему этот тайм-аут является новым.На самом деле я не сделал ничего, что могло бы объяснить это, кроме обновления до этого драгоценного камня и любых других драгоценных камней, а также очистки предупреждений об устаревании.
Кажется возможным, что в Rails 5.1+ вызовы капибары сбрасываются!намного больше, может быть, больше, чем между тестовыми примерами.Особенно, когда вы читаете эту документацию по методу и думаете о том, какой фокус был на одной странице, и рассматриваете все то, что документация reset! говорит вам, что она не сбрасывается, очищает кеш браузера / HTML 5локальное хранилище / IndexedDB / база данных Web SQL / etc - или, может быть, я это представляю, и это не ново.Но я представляю, что есть много способов, которыми он может вызвать сброс!и не попадать в этот код тайм-аута, который, вероятно, зависит от драйвера.
Вы случайно не изменили на webdrivers gem, когда обновляли Rails?
Edit: Я вернулся к chromedriver-помощнику, чтобы быть уверенным, и это было не так.Что на самом деле происходит, так это то, что мой тест провалился в одном потоке, но сервер оставил сеанс binding.pry открытым.Capybara перешел к следующему тесту, и, таким образом, чтобы получить новый сеанс, он вызвал reset!, но через 60 секунд я все еще в моем сеансе pry, и сервер все еще не готов обслуживать корневой запрос.У меня такое ощущение, что поведение капибары в потоке изменилось, в моей памяти сеанс pry, открытый во время запроса к серверу, блокировал бы сбой теста до его возвращения.Но это, видимо, уже не то, что происходит.
Как вы сюда попали?К сожалению, я понятия не имею, но это точное описание того, что происходит при получении этого сообщения.