Faraday: لن تعمل Rety Middleware بعد المحلل اللغوي

تم إنشاؤها على ٢٣ أبريل ٢٠٢١ · 4تعليقات · مصدر: lostisland/faraday

معلومات أساسية

إصدار فاراداي: 1.4.1
إصدار روبي: 2.7.2

وصف المشكلة

_NB: يرجى إعلامي إذا كان هذا ينتمي إلى faraday_middleware بدلاً من ذلك. نظرًا لأنه يتضمن اثنين من البرامج الوسيطة ، لم أكن أعرف مكان وضعه.

عند إنشاء اتصال ، أتوقع (كما هو موثق) أن البرامج الوسيطة ستعمل بالترتيب الذي تم الإعلان عنه به. ومع ذلك ، عندما يفشل أحد الطلبات وقمت بتحميل البرنامج الوسيط للتحليل :json متبوعًا بالبرنامج الوسيط :retry ، لا يتم تحليل env.body في نطاق :retry للبرامج الوسيطة :retry_if كتلة:

أحتاج إلى تشغيل كتلة :retry_if على الرسالة JSON فك ترميزها لأن مستند 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 في ٢٤ أبريل ٢٠٢١

👍2

ال 4 كومينتر

تحديث: لقد قلبت حرفياً ترتيب اثنين من البرامج الوسيطة في كتلة تكوين الاتصال (بينما كنت أفكر في أن "هذا لا يمكن أن يعمل") والآن يعمل بشكل مثالي. ترك هذا على الرغم من أنه ليس لدي أي فكرة عما يحدث وما زال يبدو وكأنه خطأ (أو على الأقل يجب أن يكون موثقًا بشكل أفضل).

mvastola في ٢٣ أبريل ٢٠٢١

أنا أغلق هذا الآن ولكن لا تتردد في المتابعة إذا كان لديك أي أسئلة أخرى

iMacTia في ٢٤ أبريل ٢٠٢١

👍2

شكرا للشرح السريع واللطيف والشامل. ليس من الصعب فهم ذلك ، لكنه غير بديهي بعض الشيء هنا. أتساءل ما إذا كانت هناك طريقة فعالة لجعلها أقل.

المستندات

لقد رأيت بالفعل الوثائق التي ربطتها ، وجعلتني أعتقد أنني أعرف ما يجب أن أفعله. (رأيت الصورة والأشياء المتعلقة بالبرامج الوسيطة "الأعمق" ، لكنني لم أعالج حقًا أنها تعني عكس الترتيب.)

الصورة المعروضة غنية بالمعلومات فيما يتعلق بالعناصر الداخلية للبرمجيات الوسيطة ، ولكن قد يكون من المفيد استكمالها بإشارة مرئية لكيفية تأثير الأمر في كتلة التكوين على أمر التشغيل.

إعدادات

علاوة على ذلك ، هناك مجموعة من التفاصيل حول هذا التنفيذ تجعل هذا الأمر غير بديهي:

هناك ثلاث وظائف مختلفة في faraday لإضافة البرامج الوسيطة ، وهي غير قابلة للتبديل: يبدو أن كل قطعة من البرامج الوسيطة تعمل مع واحدة منها فقط. هذا يجعل الأمر يبدو كما لو أن هناك ثلاث حزم (أو أوامر) برمجية وسيطة مختلفة مستقلة عن بعضها البعض.
ما تفعله هذه الأسماء / المجموعات الثلاثة المختلفة من البرامج الوسيطة غير واضح تمامًا ، نظرًا لأن معظم البرامج الوسيطة لا تعمل على طرفي مسار الطلب> الاستجابة ، سيكون المستخدم مناسبًا لافتراض أن مهام "الطلب" تحدث دائمًا قبل "الاستجابة" الأشياء ذات الصلة.
تنطبق الكلمة الأساسية للرف لإضافة البرامج الوسيطة ، use ، (بأفضل ما يمكنني قوله) في Faraday فقط على هذا النوع من البرامج الوسيطة - البرامج الوسيطة التي تغلف كلا من الطلب والاستجابة.

على أي حال ، يسعدني محاولة التفكير في بعض الأفكار إذا كنت منفتحًا على تعديل واجهة برمجة التطبيقات لهذه المشكلة. وإلا على الأقل أحصل على هذا الآن. أنا أقول هذا فقط لأنني أرى بسهولة مستخدمين آخرين يعانون من نفس الارتباك هنا.

mvastola في ٢٤ أبريل ٢٠٢١

شكرًا mvastola ، هذه تعليقات لا تقدر بثمن!
ولكي نكون منصفين ، هذه ليست المرة الأولى التي أسمع فيها عن هذه الأشياء.

عندما يتعلق الأمر بالتوثيق ، أوافق على أننا بعيدون جدًا ، لذا فإن أي مساهمة لتحسين ذلك موضع ترحيب كبير (هناك في الواقع سلسلة مناقشة حديثة جدًا حول ذلك!).

النقاط الموجودة في التكوين صالحة جدًا أيضًا ، دعني أقول فقط أن ارتباك الطرق request و response و use قد تم رفعه عدة مرات ، لدرجة أنني في الواقع ، تفكر ببساطة في إسقاطها لصالح مجرد الحصول على use ، وترك بعد ذلك للبرمجيات الوسيطة لتوثيق ماذا / متى سيتلاعبون بالطلب / الاستجابة.
لذلك أقترح عدم دفع أي علاقات عامة لتغيير واجهة برمجة التطبيقات هذه حتى الآن ، لكننا منفتحون جدًا لسماع المجتمع حول هذا الموضوع من خلال المناقشات

iMacTia في ٢٤ أبريل ٢٠٢١

👍1

هل كانت هذه الصفحة مفيدة؟

0 / 5 - 0 التقييمات