Faraday: En essayant de consigner le corps de la requête, il enregistre la réponse à la place

@nthx Je vois ça aussi ..

@stve - le rapport a-t-il un sens pour vous ?

peut-être qu'il a aussi besoin d'une configuration de demande? Pas essayé par contre..

<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

C'est une condition de course standard, je pense. Ce qui se passe ici, c'est que env[:body] a déjà été défini sur le corps de la requête. Mais au moment où la méthode log ou dump_body s'exécute, le corps de la réponse a remplacé le corps de la requête à l'intérieur env[:body] et aucune autre variable/copie n'est faite du corps de la requête d'origine, pas que cela résoudrait nécessairement les choses. env est global à la requête, nous ne devrions pas supposer que le middleware s'exécute de manière synchrone et dans l'ordre avant que l'appel ne soit effectué.

Une solution simple consisterait à utiliser deux valeurs env pour suivre les corps, une pour la demande et une pour la réponse.

Nous n'avons pas ce bogue avec les en-têtes car il y a deux valeurs distinctes : request_headers et response_headers . Alors pourquoi ne pas suivre leur exemple...

Vous pouvez également créer une deuxième env appelée request_body et stocker le corps de la requête deux fois dans env.request_body et env.body . De cette façon, tout code qui s'appuie sur le comportement existant le conserve, mais le code mis à jour tel que notre fonction de journalisation ici peut utiliser request_body s'il existe.

Si cela n'est pas corrigé en amont bientôt, je vais très probablement patcher Faraday et utiliser mon propre fork. Je ne peux pas avoir une journalisation non fiable ...

@nthx , désolé si je l'ai raté, mais quel enregistreur utilisez-vous ?
Le code a l'air bien, le seul "problème" que je peux voir concerne les procs utilisés pour évaluer le message. Ce n'est généralement pas un problème, à moins que leur évaluation n'ait lieu APRÈS le traitement de la demande.
Je ne suis pas sûr que cela soit possible avec l'enregistreur standard (synchrone), j'aimerais donc savoir lequel vous utilisez :)

En fait, j'ai utilisé mon propre enregistreur dans ce cas. Cela a fonctionné pour d'autres messages, donc je ne pensais pas que cela pourrait causer un problème.
Je vais vérifier avec un enregistreur standard et revérifier le mien, et je vous le ferai savoir.

Salut @nthx , avez-vous réussi vos tests ? Avez-vous découvert quelque chose de nouveau ?
Je voudrais clore ce sujet et comprendre si le problème réside sur Faraday ou sur l'enregistreur

Je vais fermer ceci en supposant que le défaut se trouve sur l'enregistreur car j'ai testé le standard et fonctionne bien pour moi.

@nthx n'hésitez pas à rouvrir au cas où vous auriez de nouvelles preuves indiquant que Faraday est la cause possible

J'avais toujours ce bogue, en utilisant le Logger intégré de Faraday à l'époque, mais je l'ai résolu en écrivant mon propre logger dans le middleware, et plus tard en passant de l'utilisation de Faraday à quelque chose de plus simple.

Salut @iMacTia , je suis également resté avec ce problème. J'ai trouvé ce problème reproduit lorsque vous définissez l'adaptateur avant l'enregistreur.

Ce corps de demande de journal de code :

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

Cela ne :

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

Bonjour @llxff ,

oui, c'est normal car l'ordre des middlewares est critique et l'adaptateur doit toujours être en bas.
Si vous placez l'adaptateur AVANT, la demande sera effectuée avant que l'adaptateur de l'enregistreur ne soit atteint, ce qui entraînera la journalisation de la réponse deux fois.
De plus, je relis maintenant le problème @nthx avec ceci et je viens de réaliser qu'il manque l'adaptateur dans sa pile de middlewares :

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

J'ai également vérifié le code dans la gemme Saorin et il semble complètement faux pour la même raison exacte : https://github.com/mashiro/saorin/blob/master/lib/saorin/client/faraday. rb#L16

Logique. Je ne peux pas encore le vérifier à nouveau, mais j'ai une autre idée... J'ai lu mon rapport initial et il dit :

Ceci n'est pas documenté, mais discuté dans le PR #277.

Est-ce toujours le cas, qu'il n'y a pas de documentation sur la configuration de la journalisation des réponses ?
Si les docs étaient là, alors il n'y aurait aucun doute sur la façon de le faire.

Pouvez-vous s'il vous plaît créer un ticket pour mettre à jour les documents ? Ou rouvrir celui-ci peut-être ?

Aussi - qui devrait contacter les gars de Saorin ?

Salut @nthx , vous avez tout à fait raison, notre documentation n'est actuellement pas assez détaillée (en fait, nous utilisons le Readme comme "documentation").
Dans votre cas spécifique, il y a le 3ème exemple dans la section https://github.com/lostisland/faraday/blob/master/README.md#basic -use qui montre comment utiliser le middleware de l'enregistreur, mais je suis d'accord que ce n'est pas suffisant .
Nous prévoyons d'avoir un Wiki remanié dans un futur proche qui devrait aider à atténuer ce genre de problèmes.

Selon Saorin, je vous suggère d'ouvrir un problème sur leur page en fournissant des exemples avec le code défaillant et en signalant mon commentaire, ce qui devrait les aider à retrouver le problème.
Je préfère que vous fassiez cela car vous utilisez activement leur joyau et vous serez en mesure de fournir toutes les informations supplémentaires dont ils pourraient avoir besoin.

Merci

Salut,

Je viens de voir ce problème et je comprends pourquoi ma demande n'était pas bien signée.

Nous avons créé un middleware qui ajoute une signature avant de faire la requête.
Comme nous définissons l'adaptateur avant d'utiliser le middleware, la requête a été envoyée avant d'ajouter l'en-tête d'autorisation.

L'effet secondaire était que le middleware utilisait env.body pour construire la signature et donc il utilisait le corps de réponse pour construire la signature.

Comme je définissais l'adaptateur en haut de la connexion, mes journaux étaient également erronés et je pensais que mon script de signature était également erroné.

Cordialement!