Relax activesupport/hyperclient upper bounds; fix Faraday 2 Horizon client - #463
Open
oartb wants to merge 3 commits into
Open
Relax activesupport/hyperclient upper bounds; fix Faraday 2 Horizon client#463oartb wants to merge 3 commits into
oartb wants to merge 3 commits into
Conversation
stellar-base and stellar-sdk both cap activesupport < 8.0, blocking any consumer (e.g. chat) from moving to Rails 8. Upstream main hasn't relaxed this either. Widen to < 9.0.
client.rb referenced FaradayMiddleware::FollowRedirects, but the gemspec depends on faraday-follow_redirects, which registers Faraday::FollowRedirects::Middleware instead -- FaradayMiddleware is the old, incompatible faraday_middleware gem's namespace. Under Faraday 2 the old constant doesn't exist and Client.new raises on construction before any request is made. Use the correct constant and require the gem explicitly.
Not up to standards ⛔
|
The earlier Faraday::FollowRedirects::Middleware fix was necessary but not sufficient: hyperclient < 2.0 depends on the old faraday_middleware gem, which caps faraday < 2 transitively -- so the whole dependency graph could never actually resolve to Faraday 2 in practice, making the previous fix effectively dead code. hyperclient 2.0.0 drops faraday_middleware entirely and depends on faraday >= 2 plus faraday-follow_redirects directly, matching this gem's own direction. Also: faraday-excon needs an explicit `require "faraday/excon"` under Faraday 2 (same registration-by-require pattern as follow_redirects), and the specific faraday-excon release matters too -- 1.1.0's adapter class uses a `dependency` DSL macro that doesn't exist on Faraday 2's Adapter base class; 2.2.0+ does not. Verified empirically end-to-end, not just resolved: with hyperclient relaxed and both requires added, `bundle update hyperclient faraday_hal_middleware faraday-excon` actually resolves faraday 2.14.3, hyperclient 2.0.0, faraday-excon 2.2.0 (faraday_middleware disappears from the graph entirely) -- and the full monorepo test suite passes under that real resolution: base 364, sdk 53, horizon 33 examples, 0 failures. The previous commit's fix only ever ran against Faraday 1.10.4 in practice; this is the first time the Faraday-2 path has actually been exercised.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
(Supersedes #462, which closed itself when I renamed the source branch — same origin, no other changes there.)
Three fixes needed to use this gem under Rails 8 / Faraday 2, in the order I found them:
Relax activesupport upper bound. Both
stellar-baseandstellar-sdkcapactivesupport < 8.0, which blocks any consumer from moving to Rails 8. The mostrecent release is 0.32.0 (2022-05-17) and
mainhasn't touched this constrainteither. Widened to
< 9.0.Fix the Horizon client's Faraday 2 middleware reference.
client.rbreferencedFaradayMiddleware::FollowRedirects(the old, incompatiblefaraday_middlewaregem's namespace) when the actual dependency,
faraday-follow_redirects, registersFaraday::FollowRedirects::Middlewareinstead.Relax
hyperclientand requirefaraday-exconexplicitly — this is the one thatactually matters end-to-end. Fix is this dead ? #2 alone turned out to be necessary but not
sufficient:
hyperclient < 2.0depends on the oldfaraday_middlewaregem, whichcaps
faraday < 2transitively — so the dependency graph could never actuallyresolve to Faraday 2 regardless of what fix is this dead ? #2 changed, making it dead code in
practice.
hyperclient2.0.0 dropsfaraday_middlewareentirely and depends onfaraday >= 2+faraday-follow_redirectsdirectly. Separately,faraday-exconneeds an explicit
require "faraday/excon"under Faraday 2 (sameregistration-by-require pattern as
follow_redirects), and the specific releasematters: 1.1.0's adapter class uses a
dependencyDSL macro that doesn't exist onFaraday 2's
Adapterbase class; 2.2.0+ does.Verified end-to-end, not just resolved: with all three changes,
bundle update hyperclient faraday_hal_middleware faraday-exconactually resolvesfaraday 2.14.3,hyperclient 2.0.0,faraday-excon 2.2.0(faraday_middlewaredisappears from thegraph entirely), and the full monorepo test suite passes under that real resolution:
base364,sdk53,horizon33 examples, 0 failures. Without fix #3, everythingabove still silently resolves to the old Faraday 1.x chain and never actually
exercises the Faraday-2 path fix #2 is for.