Faraday: Beim Versuch, den Anforderungstext zu protokollieren, wird stattdessen die Antwort protokolliert

@nthx sehe ich auch so..

@stve - macht der Bericht für Sie Sinn?

Vielleicht braucht es auch eine Anforderungskonfiguration? Habe das aber nicht probiert..

<strong i="6">@client</strong> = Saorin::Client.new(:url => @endpoint) do |connection|
  connection.response :logger, <strong i="7">@logger</strong>, :bodies => true
  connection.request :logger, <strong i="8">@logger</strong>, :bodies => true
end

Es ist eine normale Rennbedingung, denke ich. Was hier passiert ist, dass env[:body] einmal auf den Body der Anfrage gesetzt wurde. Aber bis die Protokollmethode oder dump_body ausgeführt wird, hat der Antworttext den Anforderungstext in env[:body] ersetzt, und es werden keine weiteren Variablen/Kopien des ursprünglichen Anforderungstexts erstellt, nicht dass dies notwendigerweise Probleme beheben würde. env ist global für die Anfrage, wir sollten nicht davon ausgehen, dass Middleware synchron und in der richtigen Reihenfolge ausgeführt wird, bevor der Aufruf erfolgt.

Eine einfache Lösung wäre, zwei env -Werte zu verwenden, um Körper zu verfolgen, einen für die Anfrage und einen für die Antwort.

Wir haben diesen Fehler bei Headern nicht, da es dort zwei separate Werte gibt: request_headers und response_headers . Warum also nicht ihrem Beispiel folgen...

Alternativ können Sie einen zweiten env dem Namen request_body und den Anforderungstext zweimal sowohl in env.request_body als auch in env.body speichern. Auf diese Weise behält jeder Code, der sich auf das vorhandene Verhalten stützt, es bei, aber aktualisierter Code wie unsere Protokollierungsfunktion hier kann request_body verwenden, falls vorhanden.

Wenn das Upstream nicht bald behoben wird, werde ich sehr wahrscheinlich Faraday patchen und meinen eigenen Fork verwenden. Ich kann keine unzuverlässige Protokollierung haben ...

@nthx , sorry, wenn ich es verpasst habe, aber welchen Logger verwendest du?
Code sieht gut aus, das einzige "Problem", das ich sehen kann, ist mit Procs, die zum Auswerten der Nachricht verwendet werden. Dies ist normalerweise kein Problem, es sei denn, ihre Bewertung erfolgt NACH der Bearbeitung der Anfrage.
Ich bin mir nicht sicher, ob dies mit dem (synchronen) Standard-Logger möglich ist, daher würde ich gerne wissen, welchen Sie verwenden :)

Tatsächlich habe ich in diesem Fall meinen eigenen Logger verwendet. Es hat für andere Nachrichten funktioniert, daher dachte ich nicht, dass es ein Problem verursachen könnte.
Ich werde es mit einem Standard-Logger überprüfen und meinen eigenen erneut überprüfen und Sie darüber informieren.

Hallo @nthx , hattest du Glück mit deinen Tests? Hast du etwas Neues entdeckt?
Ich möchte dieses Problem schließen und verstehen, ob das Problem bei Faraday oder dem Logger liegt

Ich werde dies schließen, vorausgesetzt, der Fehler liegt am Logger, da ich den Standard getestet habe und für mich gut funktioniert.

@nthx können Sie gerne wieder öffnen, falls Sie neue Beweise haben, die auf Faraday als mögliche Ursache hinweisen

Ich hatte diesen Fehler immer noch, als ich damals den eingebauten Logger von Faraday verwendete, aber ich löste ihn, indem ich meinen eigenen Logger in Middleware schrieb und später von der Verwendung von Faraday zu etwas Einfacherem wechselte.

Hallo @iMacTia , ich bin auch bei diesem Problem geblieben. Ich habe festgestellt, dass dieses Problem reproduziert wird, wenn Sie den Adapter vor dem Logger definieren.

Dieser Codeprotokoll-Anforderungstext:

Faraday.new(url: url) do |faraday|
  faraday.response :logger, ::Logger.new(STDOUT), bodies: true
  faraday.adapter Faraday.default_adapter
end

Dies nicht:

Faraday.new(url: url) do |faraday|
  faraday.adapter Faraday.default_adapter
  faraday.response :logger, ::Logger.new(STDOUT), bodies: true
end

Hallo @llxff ,

Ja, das wird erwartet, da die Reihenfolge der Middlewares entscheidend ist und der Adapter immer ganz unten sein sollte.
Wenn Sie den Adapter VORHER setzen, wird die Anfrage ausgeführt, bevor der Protokollierungsadapter erreicht wird, wodurch die Antwort zweimal protokolliert wird.
Außerdem lese ich jetzt das @nthx- Problem mit diesem Problem zurück und habe gerade festgestellt, dass ihm der Adapter in seinem Middleware-Stack fehlt:

<strong i="11">@client</strong> = Saorin::Client.new(:url => @endpoint) do |connection|
    connection.response :logger, <strong i="12">@logger</strong>, :bodies => true
  end

Ich habe auch den Code in Saorin Gem überprüft und er sieht aus genau demselben Grund völlig falsch aus: https://github.com/mashiro/saorin/blob/master/lib/saorin/client/faraday. rb#L16

Macht Sinn. Ich kann es noch nicht erneut überprüfen, habe aber einen anderen Gedanken ... Ich habe meinen ersten Bericht gelesen und es heißt:

Dies ist nicht dokumentiert, aber in #277 PR diskutiert.

Ist dies immer noch so, dass es keine Dokumentation darüber gibt, wie die Protokollierung von Antworten tatsächlich konfiguriert wird?
Wenn die Dokumente da wären, gäbe es keinen Zweifel daran, wie es geht.

Könnten Sie bitte ein Ticket erstellen, um die Dokumente zu aktualisieren? Oder vielleicht wieder öffnen?

Außerdem - wer sollte die Saorin-Jungs kontaktieren?

Hallo @nthx , du hast sehr recht, unsere Dokumentation ist derzeit nicht detailliert genug (eigentlich verwenden wir die Readme als "Dokumentation").
In Ihrem speziellen Fall gibt es das dritte Beispiel im Abschnitt https://github.com/lostisland/faraday/blob/master/README.md#basic -use , das zeigt, wie die Logger-Middleware verwendet wird, aber ich stimme zu, dass das nicht genug ist .
Wir planen, in naher Zukunft ein überarbeitetes Wiki zu haben, das helfen sollte, diese Art von Problemen zu entschärfen.

Laut Saorin schlage ich vor, dass Sie ein Problem auf ihrer Seite öffnen, das Beispiele mit dem fehlerhaften Code enthält und meinen Kommentar meldet, der ihnen helfen sollte, das Problem aufzuspüren.
Ich ziehe es vor, dass Sie dies tun, da Sie ihren Edelstein aktiv verwenden und dennoch alle zusätzlichen Informationen bereitstellen können, die sie benötigen könnten.

Danke

Hallo,

Ich habe dieses Problem gerade gesehen und verstehe, warum meine Anfrage nicht ordnungsgemäß signiert wurde.

Wir haben eine Middleware erstellt, die vor der Anfrage eine Signatur hinzufügt.
Da wir den Adapter vor der Verwendung der Middleware definieren, wurde die Anfrage gesendet, bevor der Autorisierungsheader hinzugefügt wurde.

Der Nebeneffekt war, dass die Middleware env.body zum Erstellen der Signatur und somit den Antworttext zum Erstellen der Signatur verwendete.

Als ich den Adapter oben in der Verbindung definierte, waren meine Protokolle auch falsch und ich dachte, dass mein Signaturskript auch falsch war.

Mit freundlichen Grüßen!