Faraday: Secara otomatis mengatur @handler ke Faraday.default_adapter jika dibiarkan tidak ditentukan.

Tidak yakin tentang ini, tetapi akan membiarkannya terbuka. Tumpukan default adalah UrlEncoded + default_adapter. Jika Anda mendefinisikan tumpukan Anda sendiri, maka Anda harus mendefinisikannya 100%, termasuk adaptornya. Tapi memang benar bahwa saya paling sering menggunakan default_adapter, jadi mungkin juga default.

Saya sedang berpikir tentang refactoring adaptor Faraday, menjadikannya titik akhir alih-alih middleware (sesuai # 47). Fitur ini mungkin menjadi bagian dari perubahan itu.

:+1: Ini menggigit saya untuk kedua kalinya tahun ini. Anda akan berpikir saya akan belajar. Akan lebih baik jika itu diperbaiki.

Kompromi: Faraday.with_default_stack() , sehingga kami mencurahkan jiwa yang baru pertama kali mencoba menggunakan Faraday tidak perlu tahu apa-apa tentang "tumpukan default" hanya untuk dapat mengikuti pengalihan. Wajar?

@jbrains Ya saya menyadari ini tidak ramah pengguna. Kami mungkin membuatnya sehingga kesalahan deskriptif muncul jika Anda tidak memasang adaptor, atau jika Anda memasangnya di tempat yang salah.

Saya melakukan ini di proyek saya:

        def faraday_with_default_adapter(base, &block)
          Faraday.new(base) { | connection |
            yield connection
            connection.adapter Faraday.default_adapter
          }
        end

Saya tahu Anda tidak ingin mendukung setiap permutasi, tetapi sepertinya hampir semua orang pada akhirnya akan melakukan ini. :) Jika saya tahu cara menambahkan bit UrlEncoded (saya belum menemukannya), maka saya akan menambahkannya di sini.

Pemeriksaan lint -style dengan kesalahan deskriptif pasti akan membantu. Terima kasih. Meski begitu, sedikit pokayoke akan lebih membantu kita.

Saya akan mempertimbangkan untuk mengirimi Anda permintaan tarik di masa mendatang. Sementara itu, terima kasih.

Ini menghabiskan beberapa jam kerja ketika saya mencoba membuat unggahan dan tidak menentukan adaptor default (yang saya asumsikan sudah disetel, karena ini adalah adaptor default). Saya terus men-debug dan memeriksa objek respons/permintaan dan tidak ada masalah sama sekali, kecuali saya kehilangan jalur adaptor default yang ditakuti.

Saya pikir ini setidaknya harus didokumentasikan di README di suatu tempat atau setidaknya memperingatkan saya bahwa saya memerlukan adaptor eksplisit.

Terima kasih!

Ini menggigit saya hari ini juga dengan contoh berikut:

conn = Faraday.new(url: "http://www.example.com") do |faraday|
  faraday.response :json, content_type: /\bjson$/
end

response = conn.get("stuff")

Kesalahan muncul di faraday_middleware ketika mencoba mendapatkan header respons ketika nil . Sedikit menyesatkan. Apakah keputusan telah dibuat mengenai "cara terbaik" untuk menangani ini?

• Gunakan adaptor default jika tidak ditentukan (IMO terbaik)
• Naikkan kesalahan jika tidak ditentukan
• Perbarui README

Saya akan dengan senang hati mengirimkan PR

Tidak perlu PR. Kami akan mencoba mengatasi ini di rilis berikutnya.

Terima kasih @mislav.

Yeah, aku menyia-nyiakan satu jam kemarin mengejar yang satu ini. Senang melihat perbaikan sedang dalam perjalanan. Kapan rilis berikutnya kemungkinan akan mendarat? Yang terakhir adalah Januari, yang tampaknya waktu yang sangat lama.

Pada Kam, 2 Okt 2014 jam 17:49, John [email protected]
menulis:

Kapan rilis berikutnya kemungkinan akan mendarat? Yang terakhir adalah Januari, sepertinya
waktu yang sangat lama.

Karena 0,8 dan 0,9 harus dibekukan fitur, perbaikan untuk ini kemungkinan akan
hanya datang di 1.0, yang saya tidak yakin kapan itu akan terjadi.

Bagaimana dengan ini untuk jalan tengah yang sederhana: jika upaya dilakukan untuk membuat permintaan ketika tidak ada adaptor, pengecualian akan muncul.

Atau apakah ada kasus penggunaan untuk "membuat permintaan" tanpa adaptor?

Pada Jumat, 3 Okt 2014 pukul 14:07, John [email protected]
menulis:

Bagaimana dengan ini untuk jalan tengah yang sederhana: jika ada upaya untuk membuat
permintaan ketika tidak ada adaptor, pengecualian dimunculkan.

Bagaimana kami mendeteksi jika adaptor dipasang?

Perhatikan bahwa adaptor khusus yang diterapkan oleh seseorang belum tentu memiliki
ke subkelas Faraday::Adapter.

Aku mengerti. Karena adaptor adalah saudara dari middleware lain, dan satu-satunya api yang harus diuji adalah api rak standar, tidak ada cara untuk mengidentifikasi apakah middleware adalah adaptor http. :trombon sedih:

Jika ini diterapkan, perubahan pada #496 mungkin dapat dikembalikan (jika mereka digabung terlebih dahulu).

+1 untuk ini. Paling tidak, kesalahan bahwa tidak ada adaptor yang ditentukan, atau lebih baik gunakan default_adapter jika tidak ada yang ditentukan.

Namanya membingungkan, ketika Anda harus menambahkan middlewares, Anda berharap hanya menambahkan middlewares dan mempertahankan default_adapter di tempatnya.

Ini konyol bahwa kita berakhir tanpa adaptor sama sekali. Anda tidak pernah menginginkan itu ...

Saya hanya ingin memastikan semua orang bahwa kita sedang mendiskusikan strategi untuk mengelola ini secara internal.
Saya tahu kedengarannya seperti pemeriksaan yang mudah, tetapi seperti yang sudah dijelaskan oleh @mislav , kami memiliki masalah saat ini terkait dengan kebebasan orang harus menambahkan Adaptor ke dalam tumpukan middlewares.
Faktanya, saat ini dan "adaptor" tidak lain adalah middleware, seperti yang lain, yang melakukan permintaan.
Sekarang, ketika Anda mendefinisikan tumpukan middlewares Anda sendiri, kami kehilangan kemampuan untuk mendeteksi adaptor dari middlewares lain, kecuali Anda menggunakan metode #adapter saat membangun koneksi. Sayangnya, penggunaannya tidak wajib saat ini, membuat deteksi adaptor menjadi tidak mungkin.

Dingin! Terima kasih untuk headup di sini :)

Pada 14 November 2016, pukul 14:45, Mattia [email protected] menulis:

Saya hanya ingin memastikan semua orang bahwa kita sedang mendiskusikan strategi secara internal
untuk mengelola ini.
Saya tahu kedengarannya seperti pemeriksaan yang mudah, tetapi karena
@mislav sudah menjelaskan bahwa kami memiliki masalah di
momen terkait dengan kebebasan orang harus menambahkan Adaptor ke dalam
tumpukan middleware.
Faktanya, saat ini dan "adaptor" tidak lain adalah middleware, seperti
lainnya, melakukan permintaan.
Sekarang, ketika Anda menentukan tumpukan middlewares Anda sendiri, kami kehilangan kemampuan untuk
mendeteksi adaptor dari middlewares lain, kecuali jika Anda menggunakan #adapter
metode saat membangun koneksi. Sayangnya, penggunaannya tidak
wajib saat ini, membuat deteksi adaptor menjadi tidak mungkin.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub , atau matikan suarabenang .

https://v2.developer.pagerduty.com/docs/authentication

Jadi dokumen API PagerDuty, untuk ruby+faraday, menunjukkan perilaku ini; jika Anda hanya menggunakan kode mereka, itu tidak akan berhasil. (Kecuali mereka memperbaikinya, yang mungkin akan mereka lakukan sekarang karena saya menunjukkan kurangnya adaptor.)

Sejujurnya, saran saya adalah:

Jika saya memanggil "conn.get", dan conn tidak memiliki adaptor, buat pengecualian untuk memberi tahu saya bahwa . Perilaku saat ini adalah untuk segera kembali tetapi tidak mengatur hal-hal ke status yang dijelaskan Faraday sebagai hasil dari panggilan get. Jadi misalnya, ".status" masih nihil. Ini benar-benar perilaku yang mengejutkan! Saya akan mengatakan bahwa "Saya tidak dapat melakukan apa pun karena saya tidak tahu apa yang Anda ingin saya lakukan" mungkin harus menghasilkan semacam diagnostik.

Hai @seebs Saya tahu kedengarannya konyol, tetapi saya menjelaskan mengapa ini tidak semudah dilakukan seperti yang terlihat di komentar saya sebelumnya:

Saat Anda menentukan tumpukan middlewares Anda sendiri, kami kehilangan kemampuan untuk mendeteksi adaptor dari middlewares lain, kecuali jika Anda menggunakan metode #adapter saat membangun koneksi. Sayangnya, penggunaannya tidak wajib saat ini, membuat deteksi adaptor menjadi tidak mungkin.

Saya telah mencoba menelusuri apa yang terjadi, dan saya melewatkan sesuatu.

Jika Anda melakukan hal yang jelas dilakukan banyak orang, dan tidak menentukan adaptornya, saat Anda memanggil get, Anda akhirnya berakhir di build_response rack_builder, yang melakukan app.call. Dan saya... sebenarnya tidak yakin ke mana arahnya, karena saya tidak melihat di mana aplikasi disetel.

Jadi saya kira yang saya ingin tahu adalah, jika Anda tidak pernah melakukan "adaptor :foo", apa yang akhirnya mendapatkan panggilan?

Satu solusi sepele:
def inisialisasi(penangan = [])
@penangan = penangan
jika block_given?

• self.adapter Faraday.default_adapter
  membangun (&Proc.new)
  elsif @handlers.empty?

... Saya pikir ini akan berhasil (-ish)?

Atau, setelah build(&Proc.new), periksa apakah self.adapter telah disetel.

Meskipun adapter :foo adalah cara yang paling sering digunakan untuk mengatur adaptor, ada cara lain untuk melakukannya.
#adapter sebenarnya hanya pembantu, tetapi Anda dapat menggunakan #use untuk meletakkan adaptor di tumpukan:

conn = Faraday.new(url: "http://www.example.com") do |faraday|
  faraday.response :logger
  faraday.use Faraday::Adapter::NetHttp
end

Jadi apa adaptor saat ini? Tidak lebih dari sebuah middleware yang melakukan panggilan dan menyimpan hasilnya di env . Itu sebabnya kita tidak bisa begitu saja mengandalkan metode #adapter yang dipanggil. Kami tidak dapat mengandalkan middleware yang berfungsi sebagai adaptor untuk mewarisi dari Faraday::Adapter karena itu juga bukan persyaratan.

Satu-satunya solusi adalah dengan menggunakan rilis Faraday 1.0 untuk mewajibkan penggunaan metode #adapter , atau untuk mengasumsikan bahwa itu akan digunakan dan mendorong adaptor default di tumpukan jika metode tidak dipanggil.

Kami masih mendiskusikan secara internal yang mana yang akan menjadi solusi terbaik karena satu atau lain cara kami akan membuat orang mendapatkan hasil yang tidak terduga setelah pembaruan.
Itulah yang terjadi pada banyak orang saat pertama kali mereka menggunakan Faraday, saya setuju, tetapi pasti lebih buruk ketika itu terjadi pada sistem produksi Anda setelah Anda menjalankan bundle update :)

Saya pikir apa yang saya tidak mengerti adalah... Jika Anda tidak pernah mengatur adaptor, apa yang akhirnya menangani panggilan dan menyimpan hasilnya? Ada permintaan bahwa, jika Anda memilih adaptor, saya pikir menggunakan metode call() adaptor. Jika Anda belum memilih adaptor, kode apa yang sebenarnya dieksekusi?

Di sinilah saya memilih adaptor, tanpa menggunakan metode #adapter .

  faraday.use Faraday::Adapter::NetHttp

Ambil cuplikan saya dari komentar saya sebelumnya dan coba, itu hanya akan berhasil.
Masalahnya adalah Anda dapat mendorong adaptor di tumpukan dengan banyak cara, dan begitu adaptor itu ada di sana, adaptor itu akan digunakan dalam permintaan (memanggil metode #call )

Maaf, sepertinya saya tidak jelas. Saya sadar bahwa Anda dapat memilih adaptor dengan berbagai cara.

Tetapi pertimbangkan kesalahan pemula yang umum dengan tidak memilih adaptor, dan kemudian memanggil conn.get(...). Apa yang sebenarnya terjadi, selain dari "tidak ada yang berpengaruh"?

Saya mencoba melacak melalui panggilan, dan tidak dapat mengetahui apa yang sebenarnya terjadi. Sepertinya Koneksi akan menentukan get default yang memanggil run_request. Itu pada gilirannya memanggil build_request dan build_response, dan saya pikir itu berakhir di build_response() rack_builder, yang memanggil app.call(), dan tampaknya aplikasi menghasilkan objek Response yang menangani panggilan(). Tapi kemudian saya bingung. Saya tidak melihat Response bahkan mendefinisikan metode call(), dan saya tidak tahu apa yang akhirnya membuat metode call() dipanggil.

Saya agak berasumsi bahwa ada sesuatu yang memiliki metode panggilan, yang dipanggil. Jika Anda telah memilih adaptor, Anda mendapatkan metode panggilan adaptor itu. Jika Anda belum memilih adaptor, dari mana asal metode panggilan yang benar-benar dijalankan?

Setelah mengatur permintaan dan respons, Connection menelusuri setiap middleware dan memanggil metode call(env) pada mereka, dalam urutan yang sama saat tumpukan diisi.
Itu tidak membuat perbedaan antara "middlewares normal" dan adaptor, itu hanya mengasumsikan bahwa salah satu middlewares ADALAH adaptor. Jika tidak ada "adapter middleware" di tumpukan, semua middlewares lainnya akan dipanggil ( metode call ), tetapi tidak satupun dari mereka akan secara efektif melakukan permintaan (itulah peran adaptor).
Yang berarti respons akan kehilangan status, isi, dan semua bidang lain yang diisi oleh " middleware adaptor".

Saya mengerti ini tidak mudah, tapi saya harap lebih jelas sekarang

Ah-hah! Itulah yang gagal saya pahami. Tidak terpikir oleh saya bahwa mereka semua akan menyediakan fungsi call().

Bagaimana jika, setelah memanggil semuanya, kode memunculkan pengecualian jika status tidak disetel? "StatusNotSetException: Status tidak disetel. Kemungkinan besar, middleware Anda tidak menentukan adaptor untuk benar-benar melakukan pengambilan jaringan."

Saya sangat ingin melihat ini diperbaiki!

Diperbaiki di #750 @iMacTia - maukah Anda menutup ini?

@olleolleolle ya poin bagus! Saya pikir ini akan ditutup secara otomatis dengan menyebutkannya :(

Sepertinya ini tidak pernah dirilis? Apakah ada kemungkinan untuk melihat rilis minor sebelum 1.0? :bicara_no_jahat:

@franzliedke Anda benar, ini saat ini termasuk dalam v1.0 dan saya setuju itu digabungkan beberapa waktu lalu .
Kami melakukan banyak kemajuan menuju v1.0 dan menurut saya kami cukup dekat untuk menyelesaikannya.
Coba beri kami sedikit lebih banyak waktu, itu akan sepadan dengan menunggu

Senang mendengarnya!

Maaf karena sedikit menuntut - saya tahu betapa stresnya open-source. Terima kasih untuk perangkat lunak yang hebat!

Tidak sama sekali @franzliedke !
Hargai dorongannya, kita harus benar-benar membidik dan merilis v1.0 lebih cepat daripada nanti.
Tonton reponya jika Anda belum melakukannya agar Anda tidak ketinggalan peluncurannya 👍