@adjam what would need to change in rsolr if we wanted to use faraday 2.x? Is there a way we can make it compatible with both versions?

@jcoyne not really sure -- the recommendation per the error message is to call Faraday.default_adapter with the appropriate adapter (https://lostisland.github.io/faraday/adapters/) before making any HTTP calls, but my best guess there would be that most folks are using Net::HTTP, but making that assumption might break some builds.

I haven't investigated other changes to Faraday 2 that might impact rsolr; my approach here is to issue a quick fix that should work now (since the upstream changes are breaking CI now) and take a more leisurely approach to doing a more complete investigation of what it would take to smoothly handle either Faraday version.

I think rsolr is all set for Faraday 2.x -- we just pass the adapter value through. In order to support both 1.x and 2.x implementations with no downstream impact, we just need to be explicit in falling back to the net-http adapter:

#229

Maybe annoying for people who don't want to use that adapter, but 🤷‍♂️

Can we just do:

Faraday.default_adapter ||= :net_http instead?

If you use ||=, you make sure you don't stop anyone else from using a different adapter, even if it got set before the rsolr code ran -- and of course someone can still change this after the rsolr code runs too.

So it doesn't suck for anyone, it just restores the semantics of faraday 1.0 with regard to default adapter, and allows us to be compatible with either faraday 1.x or 2.x (with regard to this anyway -- I think there may be some other faraday 2.x problems. ).

There's another faraday 2.0 problem here: #230

Looks like the 'support both' PR obviates this one.