Faraday::ParsingError with json gem >= 3.0 (ArgumentError: wrong number of arguments) #113

Description

The json gem v3.0 changed JSON.parse to accept options only as keyword arguments, dropping support for a positional options hash:

# json < 3.0
JSON.parse(source, options_hash)   # worked

# json >= 3.0
JSON.parse(source, on_load: nil, object_class: nil, array_class: nil, **options)  # keyword-only

Faraday's built-in JSON response middleware (used internally to parse Strava API responses) still calls JSON.parse positionally:

# faraday/lib/faraday/response/json.rb
decoder.public_send(method_name, body, @parser_options || {})

When json >= 3.0 is resolved in the bundle (e.g. via a fresh bundle update/bundle lock), every API call that goes through Faraday's :json response middleware fails with:

ArgumentError: wrong number of arguments (given 2, expected 1)

wrapped as Faraday::ParsingError.

Steps to Reproduce

gem 'json', '3.0.2'
require 'strava-ruby-client'

client = Strava::OAuth::Client.new(client_id: 'x', client_secret: 'y')
client.oauth_token(refresh_token: 'z', grant_type: 'refresh_token')
# => Faraday::ParsingError: wrong number of arguments (given 2, expected 1)

Expected Behavior

The client should work with json >= 3.0.

Actual Behavior

Any API response parsed via Faraday's JSON middleware raises Faraday::ParsingError wrapping ArgumentError: wrong number of arguments (given 2, expected 1).

Environment

• strava-ruby-client 3.1.0
• faraday 2.14.3
• json 3.0.2
• ruby 3.4.6 / 3.3.5

Possible Fix

This is arguably a Faraday bug (tracked upstream), but strava-ruby-client could work around it by:

• Pinning json to < 3.0 in the gemspec, or
• Configuring/patching the Faraday :json middleware to pass parser options as keyword arguments when running on json >= 3.0, or
• Tracking/depending on a Faraday release once it supports json 3.x.

As a temporary workaround, downstream apps can pin gem 'json', '< 3.0' in their own Gemfile.