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

Add an explicit fallback to net_http to support both faraday 1.x and 2.x implementations #229

Merged
merged 3 commits into from
Jan 5, 2022

Conversation

cbeer
Copy link
Contributor

@cbeer cbeer commented Jan 5, 2022

No description provided.

rsolr.gemspec Outdated
s.required_ruby_version = '>= 1.9.3'


s.requirements << 'Apache Solr'

s.add_dependency 'builder', '>= 2.1.2'
s.add_dependency 'faraday', '>= 0.9.0'
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW it looks like the faraday dependency will never be able to <1 due to faraday-net_http's requirements. Should this be bumped up to >= 1.0 to not give false hopes?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that's true -- faraday-net_http is only a dependency of faraday depending on what version of faraday you are using. If you are using faraday < 1, you don't have faraday-net_http at all. I think there's no reason for rsolr to stop letting users use a version of faraday they may be currently using without problems -- especially on a minor version release.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jrochkind faraday-net_http is being required here on the next line. From what I can see in rubygems, faraday-net_http has only every supported faraday 1.0 and higher. By adding a hard dependency on faraday-net_http here then rsolr would essentially be requiring faraday 1.0+.

Copy link
Contributor

@jrochkind jrochkind Jan 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think maybe we could have done this differently to preserve backwards compat with all previously supported faraday versions -- we didn't need to explicitly depend on faraday-net_http, and didn't need to do the require if Faraday was less than 2, which we could have checked for. Maybe. I could be wrong.

I would have appreciated y'all giving this more time for discussion and experimentation, when we are in the middle of a discussion, and I raised concerns-- what's the rush/urgency to commit this within an hour of PR'ing it?

@@ -319,7 +320,7 @@ def connection
conn.request :retry, max: options[:retry_after_limit], interval: 0.05,
interval_randomness: 0.5, backoff_factor: 2,
exceptions: ['Faraday::Error', 'Timeout::Error'] if options[:retry_503]
conn.adapter options[:adapter] || Faraday.default_adapter
conn.adapter options[:adapter] || Faraday.default_adapter || :net_http
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does Faraday.default_adapter return nil in 2.x? Why do they even have that method?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the upgrade guide, downstream consumers can set default_adapter.

@jcoyne jcoyne merged commit 0eea5eb into master Jan 5, 2022
@jcoyne jcoyne deleted the faraday-fallback branch January 5, 2022 16:26
@jrochkind
Copy link
Contributor

Note this PR changed our dependency to require faraday 1.0 instead of 0.9.0. Personally I would argue that should not be done in a minor release.

But no other committers think this/are concerned about it? I can get overruled. Would have liked to sit on this a bit longer for discussion -- is there any reason we need to be merging things effecting backwards compat the same hour they are submitted, when they are receiving discussion?

@jcoyne
Copy link
Contributor

jcoyne commented Jan 5, 2022

is there any reason we need to be merging things effecting backwards compat the same hour they are submitted, when they are receiving discussion?

I didn't see this as effecting backward compatibility. It looked to me like all points raised were addressed.

@jcoyne
Copy link
Contributor

jcoyne commented Jan 5, 2022

Note this PR changed our dependency to require faraday 1.0 instead of 0.9.0. Personally I would argue that should not be done in a minor release.

I think this is a bug fix, because we previously said any version of faraday >= 0.9.0 would work, but if you use faraday 2, it breaks.

@jrochkind
Copy link
Contributor

jrochkind commented Jan 5, 2022

Ah, I understand the urgency now, >= 9.0 meant builds would break, I see the bugfix with some urgency, thanks.

I still wish we had tried to find a way to not change the lower bound of faraday we support. But I'm also seeing faraday isn't doing what I thought it was going to do here, so the path I was thinking doesn't exactly work.

I don't myself use faraday 0.9.0, this won't be a problem for me. Just in this thing that is very "legacy" and used outside our community in who knows what ways, I think we have a responsibility to be super careful with backwards compat. But hopefully it will be fine for anyone depending on it. I think removing support for 0.9.0 is technically a backwards incompat, if faraday 1.0 could have any backwards incompats with 0.9.0, which it could.

I wonder if we should set an upper bound of < 3 to avoid running into this problem again? I think it's most responsible to always set major version upward bounds for dependencies using semver past 1.0 (which faraday now is), since it is expected the next major version will have backwards incompat of some kind, right?

@jcoyne
Copy link
Contributor

jcoyne commented Jan 5, 2022

I wonder if we should set an upper bound of < 3 to avoid running into this problem again? I think it's most responsible to always set major version upward bounds for dependencies using semver past 1.0 (which faraday now is), since it is expected the next major version will have backwards incompat of some kind, right?

Yeah, that sounds like a good idea.

@cjcolvar
Copy link

cjcolvar commented Jan 5, 2022

I would +1 making this a major release since as far as I can tell most Samvera gems aren't even on faraday 1 yet.

@iMacTia
Copy link

iMacTia commented Jan 5, 2022

Hey! I've just released Faraday 2.0.1 which brings back net_http as the default adapter.
It would be great if you could give it a try and let me know if that fixes your issue?

Thanks for using Faraday btw 🙏!

@jrochkind
Copy link
Contributor

jrochkind commented Jan 5, 2022

We may be able to do undo this becuase of the faraday correction @iMacTia mentions?

I've just released Faraday 2.0.1 which brings back faraday-net_http as a dependency and sets it as the default adapter 👍

lostisland/faraday#1358 (reply in thread)

We're still going to have a problem with the retry_503 option in #230 though....

I think releasing an Rsolr 3.0 is really a last resort, because it's so hard to get everything to upgrade RSolr versions, just to get everything to update their gemspec dependencies to allow it even if they don't need any changes to work with it... there are things still not using 2.x yet. Ideally if we were going to do a 3.0, it would be for more than faraday bookkeeping, to justify the pain of changing so many gemspecs and updating so many gems.

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

Successfully merging this pull request may close these issues.

5 participants