Skip to content

Relax activesupport/hyperclient upper bounds; fix Faraday 2 Horizon client - #463

Open
oartb wants to merge 3 commits into
astroband:mainfrom
oartb:rails8-compat
Open

Relax activesupport/hyperclient upper bounds; fix Faraday 2 Horizon client#463
oartb wants to merge 3 commits into
astroband:mainfrom
oartb:rails8-compat

Conversation

@oartb

@oartb oartb commented Aug 13, 2026

Copy link
Copy Markdown

(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:

  1. Relax activesupport upper bound. Both stellar-base and stellar-sdk cap
    activesupport < 8.0, which blocks any consumer from moving to Rails 8. The most
    recent release is 0.32.0 (2022-05-17) and main hasn't touched this constraint
    either. Widened to < 9.0.

  2. Fix the Horizon client's Faraday 2 middleware reference. client.rb referenced
    FaradayMiddleware::FollowRedirects (the old, incompatible faraday_middleware
    gem's namespace) when the actual dependency, faraday-follow_redirects, registers
    Faraday::FollowRedirects::Middleware instead.

  3. Relax hyperclient and require faraday-excon explicitly — this is the one that
    actually matters end-to-end.
    Fix is this dead ? #2 alone turned out to be necessary but not
    sufficient: hyperclient < 2.0 depends on the old faraday_middleware gem, which
    caps faraday < 2 transitively — so the dependency graph could never actually
    resolve to Faraday 2 regardless of what fix is this dead ? #2 changed, making it dead code in
    practice. hyperclient 2.0.0 drops faraday_middleware entirely and depends on
    faraday >= 2 + faraday-follow_redirects directly. Separately, faraday-excon
    needs an explicit require "faraday/excon" under Faraday 2 (same
    registration-by-require pattern as follow_redirects), and the specific release
    matters: 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.

Verified end-to-end, not just resolved: with all three changes, 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. Without fix #3, everything
above still silently resolves to the old Faraday 1.x chain and never actually
exercises the Faraday-2 path fix #2 is for.

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.
@codacy-production

Copy link
Copy Markdown

Not up to standards ⛔

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

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.
@oartb oartb changed the title Relax activesupport upper bound; fix Faraday 2 Horizon client middleware Relax activesupport/hyperclient upper bounds; fix Faraday 2 Horizon client Aug 13, 2026
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.

uninitialised constant (Stellar::Currency) is this dead ?

2 participants