Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wierd post repeat #130

Open
joshco opened this issue Sep 8, 2017 · 8 comments
Open

wierd post repeat #130

joshco opened this issue Sep 8, 2017 · 8 comments
Labels

Comments

@joshco
Copy link

joshco commented Sep 8, 2017

Strangest thing ever...
I'm using hyperclient to find a link in a root document, and then doing a _post on it with some json.
On one server this works fine.
On another, hyperclient posts the data correctly, the server returns a 200 OK with a json response body. Then hyperclient repeats the POST to the same URL, but includes the response body it got from the first response.
This then fails with a 422 as it is not a valid request body.

Any idea why hyperclient would decide to repeat a post and send the newly received body instead of what it was told to?

@dblock
Copy link
Collaborator

dblock commented Sep 8, 2017

Strange, never seen this. Is this consistently reproducible on that machine? Some ideas:

  • I would compare gem versions first, just in case something newer slipped in.
  • Hyperclient uses Futuroscope, which is a bit of magic. I would try setting the pool to no pool like here and see if it changes anything.
  • Upgrade Futuroscope to latest.
  • I would try to reduce this to a spec and record what's going on with VCR so that we can rerun it, it's likely a bug.

@dblock dblock added the bug? label Sep 8, 2017
@joshco
Copy link
Author

joshco commented Sep 9, 2017

it's all running on the same machine, but the different behavior shows up depending on which server I am talking to. The servers are two different rails server apps. Luckily the one that is causing the problem is my own app that I control.
My server works fine with CURL, the HAL browser, and doing my POST directly with Faraday, but with hyperclient I see this behavior.

I tried updating my bundle to the latest hyperclient from this repo and see the same results. I'll futz with futuroscope too.

I'm continuing to debug it. It smells to me like either a content type or encoding problem where HC can't parse the results, or HC is updating it's own internal state of the resource, spotting an error and triggering retry logic, but keeping POST as the method.

This line makes me wonder

Resource.new(response.body, @entry_point, response)

Is there any case where Resource.new will cause some HTTP action to happen?

@dblock
Copy link
Collaborator

dblock commented Sep 11, 2017

I don't think so, but did you try to turn this into a spec? If you can repeat that behavior you can record the spec with VCR and we can repro/fix.

@joshco
Copy link
Author

joshco commented Sep 12, 2017

Im still troubleshooting it, turning it into a spec isn't trivial and I'm not there yet

@dblock
Copy link
Collaborator

dblock commented Jan 5, 2018

Maybe this is Futuroscope-related. If you have a repro, try with #133.

@espen
Copy link

espen commented Jan 31, 2018

This occurred in my development as well. Not sure what triggered it as I was just trying things out. I might have triggered it via the https://github.com/charliesome/better_errors console and not in the normal Rails request. But mitmproxy showed a bunch of repeating requests that would go on forever.

@dblock
Copy link
Collaborator

dblock commented Jan 31, 2018

@espen And still present on 0.9.0? (futuroscope was removed)

@espen
Copy link

espen commented Jan 31, 2018

@dblock not sure, as it was my initial testing for a rewrite it was probably an older version. Just wanted to comment that I experienced this, sorry for the lack of details. I'm gonna assume it was due to futurescope with the old version but will investigate better if it occurs again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants