Faraday: 열기 및 읽기 시간 초과에 대한 TimeoutError 구별

안녕하세요 @coberlin 저는 이것이 좋은 추가 기능일 수 있다고 생각합니다. 저는 이전 버전과의 호환성이
그러나,이에 대한 가능한 솔루션을 가질 수 있습니다 OpenTimeoutError 및 ResponseTimeoutError 에서 상속에 TimeoutError , 그래서 기존의 rescue 예상대로의 작동 유지합니다.
확실히 테스트해볼 가치가 있습니다 😃

rack_adapter는 이 기능의 잘못된 위치일 수 있습니다. 랙 응용 프로그램이 반드시 열기 및 읽기 제한 시간을 구별하지 않는다고 생각합니다. 아마도 이 기능이 HTTPClient 어댑터나 다른 어댑터에서 작동할까요? 어댑터/httpclient.rb에서:

    @app.call env
  rescue ::HTTPClient::TimeoutError, Errno::ETIMEDOUT
    raise Faraday::Error::TimeoutError, $!
  rescue ::HTTPClient::BadResponseError => err
    if err.message.include?('status 407')
      raise Faraday::Error::ConnectionFailed, %{407 "Proxy Authentication Required "}
    else
      raise Faraday::Error::ClientError, $!
    end
  rescue Errno::ECONNREFUSED, IOError, SocketError
    raise Faraday::Error::ConnectionFailed, $!
  rescue => err
    if defined?(OpenSSL) && OpenSSL::SSL::SSLError === err
      raise Faraday::SSLError, err
    else
      raise
    end

::HTTPClient::TimeoutError에는 3개의 하위 클래스 ConnectTimeoutError, ReceiveTimeoutError, SendTimeoutError가 있습니다. 예를 들어 http://www.rubydoc.info/gems/httpclient/2.1.5.2/HTTPClient/TimeoutError 참조

Faraday에는 이미 Faraday::Error::ConnectionFailed가 있습니다. ConnectTimeoutError에 적합합니까? Faraday::Error::TimeoutError는 Faraday::Error::ReceiveTimeoutError 및 Faraday::Error::SendTimeoutError로 하위 분류될 수 있습니다.

Faraday에는 이미 Faraday::Error::ConnectionFailed가 있습니다. ConnectTimeoutError에 적합합니까?

이것은 의미가 있지만 이전 버전과 호환되지 않습니다. 사람들이 이미 애플리케이션에서 Faraday::Error::TimeoutError 를 포착하고 있으므로 ConnectionFailed 전환하면 이러한 사례가 중단된다는 점을 명심해야 합니다.
대신에 우리가 하고 싶은 것은 Faraday::Error::TimeoutError 대한 2개의 하위 클래스를 정의하는 것입니다. 그 이름은 최대한 일반적이어야 합니다.

• 패러데이::오류::OpenTimeoutError
• 패러데이::오류::ReadTimeoutError

다음 단계는 각 어댑터 로 이동하여 그에 따라 어댑터 예외를 매핑하는 것입니다. 예: HTTPClient의 경우:

• HTTPClient::ConnectTimeoutError ==> Faraday::Error::OpenTimeoutError
• HTTPClient::ReceiveTimeoutError ==> Faraday::Error::ReadTimeoutError
• HTTPClient::TimeoutError ==> Faraday::Error::TimeoutError (Faraday 또는 특정 설정에 해당 매핑이 있는지 확실하지 않은 SendTimeoutError도 catch합니다)

마지막으로 가능한 경우 테스트를 추가해야 합니다. :)

얘들 아.

우리는 이 토론을 "조금" 전에 했습니다(https://github.com/lostisland/faraday/pull/324).

다른 시도를 하고 있습니다(https://github.com/mistersourcerer/faraday/tree/718_mrsrcr_timeout-wrapping-2nd-chance). 진행 상황이 발생하는 즉시 새 PR을 시도하고 열 것입니다.

@mistersourcerer님 , 넛지 감사합니다. 토론이 진행되었다는 사실을 전혀 몰랐습니다.
PR이 닫힌 것을 보니 약간 혼란스럽습니다. 하지만 코드의 변경 사항으로 인해 결국 변경 사항이 어떻게든 병합되었음을 알 수 있습니다 😄
이전 작업의 Timeout 테스트에 이미 익숙하다고 생각하므로 이 경우 도움을 주시면 감사하겠습니다.
OpenTimeoutError 및 ReadTimeoutError 에 대한 제 설명이 명확하기를 바랍니다. 하지만 그렇지 않은 경우 알려주시기 바랍니다.
시간을 갖고 완료되면 풀 리퀘스트를 여십시오 👍

안녕하세요 @iMacTia입니다.

제 기억이 맞다면 당시 상황을 해결하지 못했습니다. 하지만 정확한 이유는 모르겠습니다.
주요 문제는 모든 어댑터에서 일관되게 실패한 테스트를 작성하는 것이었습니다. 그래서 내 코드가 그 당시에 전혀 병합되지 않았다고 생각합니다.
어쨌든, 나는 몇 년 후에 이것에 대한 아이디어를 가지고 있습니다. 하하, 그것이 어떻게 진행되는지 봅시다.

현재 _EMSynchrony_에 대한 테스트는 Travis에서 실패하지만 로컬에서는 실패합니다. 그것을 알아 내려고 노력하고 있습니다. 공개된 "초기" PR에서도 이를 논의할 수 있을 것으로 생각하고 있습니다.

그리고 당신의 설명은 수정처럼 명확하고, 그것과 함께 가는 완벽한 방법인 것 같습니다.

이것에 대한 멋진 작업에 감사드립니다.

@mistersourcerer 감사합니다!

RE 변경 사항: 무슨 일이 있었는지 잘 모르겠지만 @mislav가 마침내 변경 사항을 여기에 병합했습니다. https://github.com/lostisland/faraday/commit/f73d13ee09814fa68b37efa7bddafa47331948c2

기뻐하십시오. Errno::ETIMEDOUT 는 이미 대부분의(전부는 아닐지라도) 어댑터에서 Faraday::Error::TimeoutError 아래에 래핑되어 있습니다. 😄

@mistersourcerer 작업에 감사드립니다!

여기 커밋을 보면 이전 버전과의 호환성을 위해 Net::HTTP의 경우 OpenConnectionError < ConnectionError 및 HttpClient의 경우 OpenTimeoutError < TimeoutError 2개의 새 하위 클래스가 필요한지 궁금합니다.

이 문제와 관련하여 약간의 혼란이 있는 것 같습니다.
그 이유는 #438에서 "open timeout" 오류를 ConnectionFailed 로 처리하기로 결정했기 때문입니다. 그것은 틀림없이 최선의 결정이지만 누군가가 그 길을 가기로 결정한 것이 현실입니다.
이제 이것은 랙 어댑터뿐만 아니라 다른 모든 어댑터에도 영향을 미치며 동작이 일관되지 않을 수 있습니다.
v1.0과 동일한 동작으로 표준화할 계획이며 이 문제를 참조로 유지하겠습니다.

내 이전 댓글의 후속 조치입니다.

기본적으로 현재 열려 있는 시간 초과의 경우 Faraday::ConnectionFailed 오류가 발생하고 읽기 시간 초과의 경우 Faraday::TimeoutError 오류가 발생합니다. 서로 다른 어댑터가 현재 서로 다른 방식으로 작동하고 있지만 이것이 가장 일반적인 동작인 것 같습니다.
이것은 3년 전에 결정된 것이지만 여기에서는 전자의 경우에도 Faraday::TimeoutError 를 갖는 것에 대해 논의하고 있습니다(개방과 닫기를 구별하는 적절한 하위 클래스 포함).

한편으로는 그게 현실에 더 가까울 것이라고 이해하지만, 구현의 관점에서 문제를 분석하면 이러한 변화를 정당화하기 어렵다는 생각이 듭니다.
서비스에 전화를 걸고 ConnectionFailed 를 다시 받으면 내 전화가 처리될 수 없다는 것을 알고 있습니다. 서버에 연결되지 않았거나 호스트 이름을 확인할 수 없거나 다른 문제가 발생한 것 같습니다.
TimeoutError 를 다시 받으면 내 요청이 처리되었거나 부분적으로 처리되었을 수 있으며 응답을 놓쳤을 수 있습니다. 그것은 완전히 다른 경우이며 내가 호출한 서버에 무슨 일이 일어났는지 다시 확인해야 합니다.

open timeout을 TimeoutError 의 하위 범주로 만드는 것은 더 복잡한 도메인에서 간단한 상황(요청이 처리되지 않음)을 취하는 것을 의미하며, 무엇을 할지 결정하기 위해 반드시 추가 확인이 필요합니다. 시간 초과?

다음을 수행해야 합니다.

1. 열기 시간 초과를 버블업하는 방법 결정
2. 모든 어댑터를 동일한 동작으로 표준화

@coberlin @erik-escobedo @mislav @mistersourcerer 는 위의 사항을 고려한 후 귀하의 생각을 듣고 싶습니다 😄

열린 시간 초과 오류에 대해 ConnectionFailed 를 사용하는 것은 나에게 의미가 있으며 다른 시간 초과 오류와 열린 시간 초과 오류를 구별하여 얻고자 하는 바를 제공합니다. 어댑터 일관성의 경우 예를 들어 Net::HTTP 는 있는 그대로지만 HTTPClient 는 변경되고 ConnectTimeoutErrors는 TimeoutError 대신 ConnectionFailed로 매핑됩니다.

좋습니다. 일단 모든 어댑터를 동일한 동작으로 표준화하기로 결정하면 (v1.0에서는 분명히 이전 버전과 호환되지 않으므로)

사용 사례를 링에 던지기:

직장에서 우리는 Nginx + Kubernetes가 매달린 포드(또는 무언가)로 라우팅하지 못하기 때문에 일부 Open Timeouts로 고통받고 있습니다. 어쨌든 NetHTTP는 OpenTimeout 및 ReadTimeout 오류를 발생시키는 데 사용되었으며 디버깅하는 데 정말 편리했습니다.

이제 우리는 Typhoeus로 전환했습니다. 슬프게도 모든 시간 초과가 함께 뭉쳤습니다. nginx + kuber 문제에 대한 작업이 개선되었는지, 아니면 이제 막 점점 더 어려움을 겪고 있는 문제에 대해 더 많은 요청을 성공적으로 수행하고 있는지 말하기 어렵습니다. 체계. 어느 쪽이든 제한 시간의 수는 거의 같으며 분리하지 않고 추측하는 데 어려움을 겪습니다.

Faraday::OpenTimeoutError 추가하는 것만으로는 충분하지 않다고 생각합니다. Faraday::TimeoutError IMO에서 Faraday::OpenTimeoutError 및 Faraday::ReadTimeoutError 확장되어야 합니다.

@philsturgeon 과 다른 제안된 솔루션은 어떻습니까?

열기 시간 초과 -> Faraday::ConnectionFailed
읽기 시간 초과 -> Faraday::TimeoutError

이는 모든 어댑터에서 작동해야 하지만 불행히도 일부 어댑터는 예상대로 작동하지 않습니다(예: Typhoeus).

그런 것들이 다른 것 같아요.

ConnectionFailed는 잘못된 DNS/IP 등과 같이 "이 서버와 통신하는 방법을 모릅니다"와 같습니다.

OpenTimeout은 "나는 이 서버가 어디에서 일을 하기를 기다리고 있는지 알고 있습니다."

OpenTimeout은 "나는 이 서버가 어디에서 일을 하기를 기다리고 있는지 알고 있습니다."

나는 그것에 동의하지 않는다. 나는 차라리 이렇게 말하고 싶다.

Open Timeout: 서버에 접속하려고 하지만 접속할 수 없습니다(참고: 연결이 아직 설정되지 않았거나 "열림").
읽기 시간 초과: 서버와 연결을 설정했지만 작업(출력 읽기)을 수행하기를 기다리고 있습니다.

결함이 있는 방화벽/프록시/load_balancer는 공개 시간 초과가 발생할 수 있는 방법의 간단한 예일 뿐이지만 이 모든 경우에 서버에 대한 연결이 아직 시작되지 않았습니다. 그것은 나에게 가장 중요한 부분입니다. "ConnectionFailed"는 단순히 서버에 연결할 수 없음을 의미합니다. 그리고 그것은 이러한 경우에 완벽하게 맞습니다.

당신은 여전히 특정 패러데이 :: OpenTimeoutError이 존재해야한다고 생각한다면, 나는로부터 상속 할 것을 건의 할 것입니다 ConnectionFailed 보다는 TimeoutError 그러나 나는 확실히 어떻게이 조금 혼동 될 것이다 동의하지 실무에 도움이 될 것입니다.
이것이 실제로 오류를 관리하는 데 어떻게 도움이 되는지에 대해서는 이전 https://github.com/lostisland/faraday/issues/718#issuecomment -343957963을 참조하십시오.

말이 되나요? 모두에게 맞는 솔루션을 찾고 싶습니다

개방 시간 초과에 대한 귀하의 보다 정확한 정의에 동의하지만 다른 결론에 도달합니다.

해당 연결을 기다리려는 시간이 연결의 일부로 간주되므로 열기 시간 초과를 연결 실패로 간주합니다. "5초만에 연결 실패"는 그렇게 설명하면 확실히 이해가 되지만 많은 사람들이 생각하는 방식은 아닙니다.

많은 경우 open timeout은 아직 발생

연결 실패와 열기 시간 초과를 모두 다시 시도해야 하므로 여기에서 읽기 시간 초과가 취소 사유로 간주될 수 있으므로 그다지 중요하지 않다고 생각합니다.

동의합니다. 읽기에 대해 우리가 원하는 만큼 논쟁할 수 있지만 적용할 수 있지만 제 요점의 실용성은 당신이 말한 것이기도 합니다. Open Timeout을 받으면 요청을 다시 시도할 수 있다는 의미입니다. 읽기 시간 초과는 요청이 처리되었을 수 있으므로(전체 또는 부분적으로) 매우 주의해야 함을 의미합니다. 우연히도 open timeout의 실질적인 의미는 실패한 연결의 의미와 일치하므로 거기에서 상속하도록 하겠습니다.

오늘날 사람들은 ConnectionFailed 및 TimeoutError 예외를 포착하고 있으며 그 뒤에 있는 논리는 아마도 우리가 이전에 말한 것을 반영하고 있을 것입니다. ConnectionFailed 의 하위 클래스로 새 예외를 도입하면 대부분의(전부는 아니지만) 응용 프로그램에 변경이 필요하지 않을 가능성이 높습니다.

OpenTimeout이 타임아웃의 또 다른 유형이라는 것을 의미론적 관점에서 이해하고 동의합니다.

하지만 대신 ConnectionTimedOut 라고 하면 어떨까요?

open_timeout: X 가 ConnectionTimedOut 던질 때까지 기다려야 하는 시간을 나타내는 속성의 이름에 대해 약간의 혼란이 있을 것입니다.

좋은점 😞

ConnectionOpenTimeout 합니까? 연결 문제를 해결하고 열기 시간 초과를 분명히 합니다. 나는 이 이름이 "Failed to make connection in Xseconds"의 의미에 따라 이해를 계속하고 있다고 생각합니다. 비록 일부 사람들은 여전히 ​​시간 초과가 시간 초과가 아닌 이유를 궁금해 할 수 있지만 말입니다. 😂

나에게 좋은 소리 👍!

@iMacTia 이봐, 어디서부터 시작해야 하는지 알려주시면 이 작업을 수행할 수 있습니다.

@philsturgeon 감사합니다. 이에 대한 주요 요점을 요약하자면 다음과 같습니다.

1. 모든 변경 사항은 v1.0 분기에 대해 수행해야 합니다(이전 버전과 호환되지 않음).
2. 시간 초과 관리 동작은 어댑터 간에 일관되지 않으므로 이를 표준화해야 합니다.
3. 합의된 행동은 다음과 같습니다.
4. OPEN 시간 초과의 경우 ConnectionFailed 에서 상속되는 ConnectionOpenTimeout 오류가 발생합니다.
5. READ 시간 초과의 경우 TimeoutError 합니다.

내가 놓친 게 있니?

ConnectionOpenTimeout 가 기본 Faraday::Request::Retry 처리 예외에 추가됩니까?

@mjhoy 좋은 지적이지만 현재 Retry 미들웨어는 연결 문제의 경우 재시도하지 않습니다. 연결에 성공했지만 시간 초과가 발생한 경우에만 요청을 재시도합니다. 실제로 호출한 서비스에 전혀 연결할 수 없는 경우 요청을 재시도하는 것이 의미가 있는지 잘 모르겠습니다. 예외를 다시 가져오고 이 경우 다른 작업을 수행하는 것이 좋습니다.

그러나 Faraday::Request::Retry 는 구성 가능하므로 처리하려는 예외 목록에 ConnectionOpenTimeout 또는 ConnectionFailed 를 추가하는 것을 막을 수는 없습니다.

기본 예외 목록에 추가하기 전에 "커뮤니티 의견"을 더 보고 싶습니다.

때때로 재시도해야 하는 API 엔드포인트에서 OpenTimeout 오류가 발생합니다. 위 의 Errno::ETIMEDOUT, Timeout::Error, Error::TimeoutError 이고 Net::OpenTimeout 는 Timeout::Error 의 하위 클래스입니다. 패러데이가 그들을 다르게 대하고 있다는 것은 특히 분명하지 않았습니다. 그래서 아마도 문서를 업데이트해야 할까요? 어쨌든 우리는 미들웨어를 구성했습니다. 기본값이 의미가 있는지 궁금합니다.

@mjhoy Timeout::Error 에는 Net::OpenTimeout 도 포함되어 있으므로 현재 구현에서는 열기 제한 시간도 다시 시도해야 하는 것처럼 보입니다. 게다가 Timeout::Error 는 정상적인 상황에서 어댑터에 의해 구출되고 다시 발생 하므로 예외 목록에 있는 것이 불필요하거나 추가 안전을 위해 있을 수 있습니다.

예외 리팩토링이 끝나면 Net::OpenTimeout 가 새로운 예외로 발생하고 내 의견에서 말했듯이 현재 기본 동작을 변경합니다.

나는 여전히 그것이 기본값의 일부가 아니어야 한다고 생각하지만 작업을 수행하는 동안 확실히 고려해야 할 사항입니다.

올려주셔서 감사합니다 😄

안녕하세요, 1년 동안 팀 백로그에서 이것이 시들해져서 죄송합니다. 이제 우리의 우선 순위가 많이 바뀌었습니다. 이 문제에 대해서는 아무 작업도 하지 않겠지만 행운을 빕니다!

@iMacTia 이 변경 작업을 하는 사람이 있습니까? 나는 이것을 v2.0에 적용하는 것을 꺼리지 않는다.

안녕하세요 @ragav0102 , 지원해주셔서 감사합니다!
우리는 여전히 v1.0을 출시하기 위해 노력하고 있기 때문에 아직 아무도 이 작업을 하고 있지 않습니다.

도움을 주시면 감사하겠습니다. 하지만 아직 v2.0에 대한 계획이 없으므로 언제 출시될지 알 수 없으므로 변경 사항을 사용하려면 몇 달을 기다려야 할 수 있습니다.

프로젝트 중 하나에서 이것이 필요하다면 아마도 실현 가능하지 않을 것입니다.
방금 통과했고 기여하고 싶다면 v1.0이 훨씬 더 빨리 출시될 예정인 것을 선택하는 것이 좋습니다 😄

알았어요!