Faraday: Rety 미들웨어는 파서 후 실행되지 않습니다

에 만든 2021년 04월 23일 · 4코멘트 · 출처: lostisland/faraday

기본 정보

패러데이 버전: 1.4.1
루비 버전: 2.7.2

문제 설명

_NB: 대신 faraday_middleware 속하는지 알려주세요. 미들웨어가 2개나 들어있어서 어디에 넣어야 할지 몰랐어요._

연결을 생성할 때 (문서화된 대로) 미들웨어가 선언된 순서대로 실행될 것으로 예상합니다. 그러나 요청이 실패하고 :json 파싱 미들웨어 다음에 :retry 미들웨어를 로드하면 :retry 미들웨어의 :retry_if 범위에서 env.body 가 파싱되지 않습니다. :retry_if 블록:

JSON -decoded 메시지에서 :retry_if 블록을 실행해야 합니다. 요청이 성공하면 JSON 문서가 매우 커질 수 있고 대안은 retry_if , 완전히 불필요해 보입니다.

재현 단계

<strong i="23">@_client</strong> ||= Faraday.new(url: ROOT_URL) do |f|
      f.options[:timeout] = 10
      f.headers['Content-Type'] = 'application/json'
      f.use :instrumentation, name: INSTRUMENTATION_EVENT_NAME
      f.response :json, content_type: /\bjson$/
      f.request :retry, FARADAY_RETRY_OPTIONS
end

참고: 블록 내부에 f.instance_variable_get :@handlers 인쇄하면 선언한 순서대로 미들웨어가 표시됩니다.

요청이 실패하고 :retry 미들웨어의 :retry_if 블록에서 이러한 표현식을 평가하면 다음 출력이 표시됩니다.

(byebug) environment.response.to_hash.without(:url)
{:status=>405, :body=>"{\"message\": \"The method is not allowed for the requested URL.\"}\n", :response_headers=>{"date"=>"Fri, 23 Apr 2021 18:17:16 GMT", "content-type"=>"application/json", "content-length"=>"64", "connection"=>"keep-alive", "server"=>"gunicorn", "allow"=>"HEAD, OPTIONS, GET"}}

(byebug) environment.response.body
"{\"message\": \"The method is not allowed for the requested URL.\"}\n"
(byebug) environment.response.body.class
String

기본적으로 파싱 미들웨어는 먼저 실행을 거부합니다.

JSON이 잘 구성되어 있고 응답의 Content-Type 헤더가 올바르게 설정되어 있어서 당황스럽습니다.

내 유일한 추측은 #response 미들웨어가 항상 #request 미들웨어보다 먼저 실행되지만 이 경우 retry 가 #request 미들웨어는 잘못된 명칭입니다. 응답이 반환된 후 암시적으로 평가되어야 하기 때문입니다.

출처

mvastola

가장 유용한 댓글

안녕하세요 @mvastola님 , 지금 겪고
처음에는 머리를 굴리기가 어렵다는 것을 알고 있지만 미들웨어 스택의 특성이 랙 스택과 유사하기 때문에 미들웨어는 응답을 위해 역순으로 트래버스됩니다.
우리 웹 사이트 에는 이해하기 쉽도록 이것을 보여주는 그림이 있습니다.

그러므로 당신은 이미 옳은 일을했습니다 🙌! :json 미들웨어를 :retry 이후로 이동하면 응답이 먼저 처리되도록 허용하고 :retry 미들웨어는 구문 분석된 응답 본문을 찾습니다.

지금 종료하지만 추가 질문이 있으면 언제든지 문의해 주세요.

iMacTia 에 2021년 04월 24일

👍2

모든 4 댓글

업데이트: 말 그대로 연결 구성 블록에서 두 미들웨어의 순서를 뒤집었고("이것이 작동할 수 없습니다"라고 생각하면서) 이제 완벽하게 작동합니다. 무슨 일이 일어나고 있는지 전혀 모르고 여전히 버그처럼 보이기 때문에(또는 적어도 더 잘 문서화되어야 하기 때문에) 이것을 남겨둡니다.

mvastola 에 2021년 04월 23일

지금 종료하지만 추가 질문이 있으면 언제든지 문의해 주세요.

iMacTia 에 2021년 04월 24일

👍2

빠르고 친절하고 자세하게 설명해주셔서 감사합니다. 이해하기 어렵지는 않지만 여기에서는 약간 직관적이지 않습니다. 효과적으로 줄일 수 있는 방법이 있는지 궁금합니다.

문서

나는 당신이 링크한 문서를 실제로 보았고, 내가 해야 할 일을 알고 있다고 생각했습니다. (나는 그림과 "가장 안쪽에 있는" 미들웨어에 대한 내용을 보았지만 그것이 순서를 반대로 한다는 것을 의미한다고 실제로 처리하지는 않았습니다.)

표시된 이미지는 미들웨어의 내부와 관련하여 정보를 제공하지만 구성 블록의 순서가 실행 순서에 미치는 영향을 시각적으로 표시하여 이를 보완하는 데 도움이 될 수 있습니다.

구성

그 외에도 직관적이지 않게 만드는 이 구현의 세부 사항이 많이 있습니다.

faraday 에는 미들웨어를 추가하기 위한 세 가지 다른 기능이 있으며 상호 교환할 수 없습니다. 각 미들웨어는 그 중 하나만 작동하는 것 같습니다. 이것은 마치 서로 독립적인 3개의 서로 다른 미들웨어 스택(또는 순서 지정)이 있는 것처럼 보이게 합니다.
미들웨어의 이 세 가지 다른 이름/그룹이 하는 일은 매우 불분명하지만 대부분의 미들웨어는 요청->응답 경로의 양쪽 끝에서 실행되지 _않기_ 때문에 사용자는 "요청" 작업이 항상 "응답"보다 먼저 발생한다고 가정하는 경향이 있습니다. 관련된 것들.
미들웨어를 추가하는 rack 키워드 use 는 패러데이에서 요청과 응답을 모두 감싸는 미들웨어인 미들웨어에만 적용됩니다.

어쨌든 이 문제에 대해 API를 조정할 수 있는 경우 몇 가지 아이디어를 생각해 볼 수 있어 기쁩니다. 그렇지 않으면 적어도 나는 지금 이것을 얻습니다. 여기에서 같은 혼란을 겪고있는 다른 사용자를 쉽게 볼 수 있기 때문에이 말을하는 것입니다.

mvastola 에 2021년 04월 24일

@mvastola 감사
그리고 공정하게 말해서, 나는 이것에 대해 처음 듣는 것이 아닙니다.

문서화에 관해서는 우리가 아직 멀었다는 데 동의합니다. 따라서 개선을 위한 기여는 매우 환영합니다(실제로 이에 대한 매우 최근 토론 스레드 가 있습니다!).

구성에 대한 요점도 매우 유효합니다. request , response 및 use 메서드 혼동이 여러 번 발생하여 실제로 use 를 사용하기 위해 단순히 삭제하는 것을 고려하고 미들웨어에 남겨두고 요청/응답을 조작할 항목/시기를 문서화합니다.
따라서 아직까지는 PR을 통해 해당 API를 변경하지 말 것을 제안하지만 토론을 통해 이 주제에 대한 커뮤니티의 의견을 들을 수 있습니다.

iMacTia 에 2021년 04월 24일

👍1

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Faraday: Rety 미들웨어는 파서 후 실행되지 않습니다

기본 정보

문제 설명

재현 단계

가장 유용한 댓글

모든 4 댓글

문서

구성

관련 문제