Strange issues after #198

[trevorturk]

I'm not completely sure what's going on yet, but I'm seeing some strange errors (in the test env), perhaps breaking VCR / WebMock compatibility (?) since #198. Reporting before investigating further in case this rings any bells. Thanks!

[ioquatix]

Thanks let me take a look today.

[trevorturk]

I did a bit more investigating with the latest async gems and I think I got a bit closer to what the actual issue may be. In my case, I have an upstream data source with a "paid" and a "free" option -- I use the "paid" option, but if I have a rate limit error, I fall back to the "free" option, in case my paid subscription fails for some reason.

In this case, the "free" option is http, while the "paid" option is https. (http://api.geonames.org vs https://secure.geonames.net) -- I'm still having trouble understanding what might be going wrong in the VCR case. When recording the cassette everything works fine, but on subsequent runs (using the cassette) I get a timeout (no matter how high I set the timeout to be...)

I think this weird setup is actually safe for me to remove, but I thought it may be interesting to report, just in case this is helpful for debugging? Let me know if any of this triggers any additional thoughts and I'm happy to help trying to figure out if there's a fixable root issue! Thanks!

[izaguirrejoe]

@trevorturk I'm running into another "works on the first run" VCR bug. I'm not using async-http though, so I opened up an issue in the Async repo with a script that reproduces the bug. May or may not be related to this?

[trevorturk]

I just saw that come in! Yeah, I'm fairly confident that my issue was to do with multiple hosts, I wonder if you know what HTTP library you're using (under the hood in RubyLLM perhaps? I don't know the gem...)

You might also want to check here: https://github.com/search?q=repo%3Avcr%2Fvcr+async&type=issues

I had some strange issues with VCR (IIRC something to do with WebMock) that might be worth trying to research...

[izaguirrejoe]

RubyLLM uses Faraday under the hood, which I suspect is the problem. I wasn't able to reproduce my bug using async-http + VCR, so our issues might be unrelated.

[ioquatix]

I have been trying to reproduce socketry/async#381 but have not had much success. For sure, concurrency can sometimes cause tricky bugs...

"works on the first run" VCR bug

Wouldn't this basically just be running without VCR - the first run generates the fixtures and the subsequent run uses those fixtures? So wouldn't this basically just be a bug with the fixtures? If so, can you share the failed fixtures and/or test cases?

[trevorturk]

I think @izaguirrejoe's issue is likely unrelated to mine, which seems to be around mixing http and https connections. Would it be helpful for me to try to put together a minimal reproduction?

[ioquatix]

Yes, extremely helpful.

[trevorturk]

I'm unable to reproduce this with the latest async-http, so I'll close. Sorry for the noise! I'll report back if I see the issue again in the wild. Thanks!

[ioquatix]

Is it worth pinning the versions to those that were present at the time you identified the issue to confirm it's now gone away?

[trevorturk]

I'm sorry to say I spent some more time on this today and I'm not able to reproduce even going back to the old configuration in my app. I'm not sure where I went wrong, but I think we should consider this closed with the explanation being that I screwed up something somehow and don't know what! 😭

[ioquatix]

Thanks for your efforts!