Making read-only request breaks subsequent write requests

[marckohlbrugge]

See algolia/algoliasearch-rails#397 for more background info.

• Algolia Client Version: 2.0.4
• Language Version: ruby 2.7.2

Description

algoliasearch-client-ruby/lib/algolia/http/http_requester.rb

Lines 67 to 71 in 5e7c715

	def connection(host)
	@connection ||= Faraday.new(build_url(host)) do |f|
	f.adapter @adapter.to_sym
	end
	end

When making a read request the HttpRequester memoizes a @connection with a read-only host. If afterwards you try to make a write request, then HttpRequester will ignore the supplied write host and instead use the memoized @connection which was created with the read-only host. This leads to the following error:

Algolia::AlgoliaHttpError: This host is read-only (ie. this is a DSN), write operations are not accepted

Steps To Reproduce

I'm using the algoliasearch-rails gem which I think makes a check_settings read-request automatically. So any write request fails. Here's a code example using just algolia-client-ruby:

client = Algolia::Search::Client.create "…", "…"
index = client.init_index("…")

# Make a read request
index.search("a")

# Make a write request
index.save_objects([objectID: 1, name: "Foo"])

# You will get this error
# *** Algolia::AlgoliaHttpError Exception: This host is read-only (ie. this is a DSN), write operations are not accepted

Proposed solution

Make sure the connection is specific to the provided host. Something along these lines:

def connection(host)
  @connections[host] ||= Faraday.new(build_url(host)) do |f|
    f.adapter @adapter.to_sym
   end
 end

[marckohlbrugge]

Does anyone have any temporary workarounds for this? My bug reporting tool shows I've ran into this issue 27,000+ times now 😅

[marckohlbrugge]

I took a stab at it, but I just get Algolia::AlgoliaUnreachableHostError: Unreachable hosts exceptions

marckohlbrugge@385b6b5

[chloelbn]

Hi @marckohlbrugge ! I think your best bet at the moment is to reset the connection if the accept type is different from the one of the host you're passing.
One way of doing this might be to take advantage of the context you can pass while building your connection with Faraday, and compare it to the host accept parameter.

[marckohlbrugge]

@chloelbn Thanks for the suggestion. Do you have any idea why marckohlbrugge@385b6b5 doesn't work as expected? I think the original implementation was meant to be something like this, considering the code comments referring to @connections (plural).

[marckohlbrugge]

@chloelbn I was able to fix the bug with your suggestion of using the accept parameter. Here's my fix:

master...marckohlbrugge:master

I couldn't get the test suite to run, so I haven't added any test coverage. Let me know if you'd like me to open a PR anyway.

[chloelbn]

@marckohlbrugge a PR would be great indeed! Thanks a lot for your work!