Skip to content

Support Faraday 2 alongside 1.x#334

Open
Tonkpils wants to merge 2 commits into
mainfrom
tonkpils/faraday2-dual-compat
Open

Support Faraday 2 alongside 1.x#334
Tonkpils wants to merge 2 commits into
mainfrom
tonkpils/faraday2-dual-compat

Conversation

@Tonkpils

@Tonkpils Tonkpils commented Jun 22, 2026

Copy link
Copy Markdown
Member

What

Makes elastomer-client work on both Faraday 1.x and 2.x

Why

elastomer-client's faraday constraint was already open (>= 0.17), but it depended on the deprecated faraday_middleware, which pins faraday to ~> 1.0. The only thing actually used from it was the :gzip middleware.

Changes

  • Swap faraday_middleware for faraday-gzip (works on both 1.x and 2.x). It registers :gzip on Faraday::Request, so conn.use(:gzip) becomes conn.request(:gzip).
  • Faraday 2 removed Connection#token_auth/#basic_auth. The :authorization middleware isn't a clean swap (its API and header output differ across majors), so set the Authorization header directly. Verified byte-identical to Faraday 1.x's token_auth/basic_auth output (Token token="..." / Basic <base64>).
  • gemspec: faraday >= 1.0, < 3, drop faraday_middleware, add faraday-gzip. Bump to 6.3.0.
  • All 5 custom middleware already use Faraday 2 patterns (Faraday::Middleware + @app.call/on_complete), no changes needed.

Test changes (necessitated by the above)

  • Auth tests spied on the removed token_auth/basic_auth methods — now assert the resulting Authorization header (no live server needed). The spy dev dep is no longer used.
  • The block-config test referenced the gone FaradayMiddleware::Instrumentation — swapped for elastomer's own :opaque_id.
  • The retry test looked up the relocated retry class via the middleware registry.

CI

Added a Faraday 1.x / 2.x gemfile matrix so both majors are tested against the same ES versions.

elastomer-client was pinned to Faraday 1.x through faraday_middleware
(deprecated, caps faraday at ~> 1.0). The only thing it used from that gem was
the :gzip middleware, so swap it for faraday-gzip, which works on both Faraday
1.x and 2.x and registers :gzip on Faraday::Request (hence conn.request(:gzip)
instead of conn.use(:gzip)).

Faraday 2 also removed the Connection#token_auth and #basic_auth helpers. The
:authorization middleware isn't a clean substitute since its API and header
output differ across majors, so set the Authorization header directly. Verified
the output is byte-identical to Faraday 1.x's token_auth/basic_auth.

gemspec now allows faraday >= 1.0, < 3 and drops faraday_middleware. Bump to
6.3.0.

Test updates this required: the auth tests spied on the removed
token_auth/basic_auth methods, so assert on the resulting Authorization header
instead (no live server needed). The block-config test used the gone
FaradayMiddleware::Instrumentation, swapped for elastomer's own :opaque_id. The
retry test looked up the relocated retry class via the registry. The spy gem is
no longer used.
GitHub Advanced Security started work on behalf of Tonkpils June 22, 2026 16:23 View session
GitHub Advanced Security finished work on behalf of Tonkpils June 22, 2026 16:24
Add a gemfile matrix axis so CI proves dual compatibility on both Faraday majors
against the same Elasticsearch versions. The faraday_2 lane pulls faraday-retry
(the :retry middleware that left core) for the retry coverage.

Also move checkout ahead of setup-ruby so bundler-cache can see the matrix
gemfile pointed to by BUNDLE_GEMFILE.
@Tonkpils Tonkpils force-pushed the tonkpils/faraday2-dual-compat branch from d99c89a to ec2061d Compare June 22, 2026 16:25
GitHub Advanced Security started work on behalf of Tonkpils June 22, 2026 16:26 View session
GitHub Advanced Security finished work on behalf of Tonkpils June 22, 2026 16:36
@Tonkpils Tonkpils marked this pull request as ready for review June 22, 2026 16:41
Copilot AI review requested due to automatic review settings June 22, 2026 16:41

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

Updates elastomer-client to support both Faraday 1.x and 2.x by removing the deprecated faraday_middleware dependency and adjusting connection/auth setup and tests/CI to be compatible across both majors.

Changes:

  • Replace faraday_middleware with faraday-gzip and update gzip middleware wiring.
  • Remove usage of token_auth / basic_auth helpers and set Authorization header directly for consistent output across Faraday 1/2.
  • Add CI Gemfile matrix (Faraday 1.x + 2.x) and adjust tests to assert headers/lookup middleware appropriately.
Show a summary per file
File Description
lib/elastomer_client/client.rb Switch gzip middleware dependency/usage and implement cross-version auth header handling.
test/client_test.rb Update tests to validate Authorization header output and Faraday 1/2 retry middleware lookup; swap removed instrumentation reference.
elastomer-client.gemspec Constrain Faraday to >= 1.0, < 3 and replace faraday_middleware with faraday-gzip.
Gemfile Add faraday-retry for Faraday 2 default dev/test bundle; drop unused spy.
gemfiles/faraday_1.gemfile Add a dedicated Faraday 1.x test Gemfile for CI matrix.
gemfiles/faraday_2.gemfile Add a dedicated Faraday 2.x test Gemfile (including faraday-retry).
.github/workflows/main.yml Run CI against both Faraday majors via BUNDLE_GEMFILE matrix.
lib/elastomer_client/version.rb Bump version to 6.3.0.
CHANGELOG.md Document the Faraday 2 compatibility release.
.gitignore Ignore generated per-gemfile lockfiles (gemfiles/*.lock).

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

  • Files reviewed: 9/10 changed files
  • Comments generated: 0

@tomthorogood tomthorogood left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

@Tonkpils Thanks for doing this; we will also need to update github/github to use the new version of this client once it is released. I can take care of that, just wanted to let you know it won't flow in automatically on merge. ❤️

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.

3 participants