Changing configuration does not affect current connection

[AdoPi]

Hello :wave: Firstly, we use this configuration : MeiliSearch::Rails.configuration = {meilisearch_host: 'http://localhost:7700', meilisearch_api_key: "MasterKeySampl" }

Then, after the first successful connection, we want to simulate a connection lost error. We are trying to update Meillisearch::Rails.configuration MeiliSearch::Rails.configuration = {meilisearch_host: 'error_host'}

Client object seems to be changed as you can see here: #<MeiliSearch::Client:0x0000000114cff458 @base_url="error_host", @api_key=nil, @options={:timeout=>1, :max_retries=>0, :convert_body?=>true, :client_agents=>"Meilisearch Rails (v0.7.3)"}, @headers={"Content-Type"=>"application/json", "User-Agent"=>"Meilisearch Rails (v0.7.3);Meilisearch Ruby (v0.19.2)"}>

But instead of getting an error ( like MeiliSearch::CommunicationError) the connection still works.

How are we supposed to do to change the connection on the fly?

For information, we are using ActiveSupport::TestCase to test our code.

[AdoPi]

After some investigations, we found that each ActiveRecord model has its own instance of SafeIndex and each SafeIndex has its own HTTP client, am I right?

This is why when we update MeiliSearch::Rails.configuration it does not affect the existing Index but only the new ones.

I'm not sure if it's a bug or a feature.

[brunoocasali]

Hi @AdoPi!

Yes indeed! This is the current behavior. Can you tell me more about why you want to change the configuration on the fly?

The current system was implemented to avoid multiple calls to expensive internal routines (network-wise or memory-wise). So I'm unsure if the best way is to implement a method to update the configuration + reload everything or understand when the configuration changes and then automatically reload the internal Safe Indexes.

Thanks a lot for your issue ;)

[AdoPi]

Sure, thanks for your reply :) We are using a container which is accessible by contacting http://meilisearch:7700 but we wanted to simulate that this container could be unreachable sometimes for some reason and be sure our app would be tolerant to this.

Our simple idea was to change the configuration on the fly ( during the test stage ) to something like http://errorhost:7700, it was easier for us to do this instead of forcing the container to restart during the execution of the testcases.

Another case I'm thinking of is migrating a meilisearch service to another domain name or another port. I guess this case could happen more often than our case which is a bit more specific.

As the gem currently works, I think it is not really intuitive having to reindex every model to be sure our new domain name is used instead of the old one.

[brunoocasali]

Hi @AdoPi,

I'm closing this issue since the refactoring needed to make your suggestion work way out of our league in terms of human resources. I would appreciate it if someone else could refactor that code, but nobody has come since this issue was opened for a long time.

So, I don't see a reason to keep this open anymore.