Behavior of the health() method

[curquiza]

I notice each SDK has its own version of handling the health method.
I suggest we find the best way to handle it.

Currently, the GET /health route returns 204 without any body if MeilISearch is running. If MeiliSearch is not running, the SDK would catch another error/exception (ConnectionRefused for example) but not an error coming from the MeiliSerach API.

Option A 😁

health():

• returns true when MeiliSearch is healthy.
• returns false when MeiliSearch is unhealthy (an error is caught)

Option B 🎉

health():

• returns true when MeiliSearch is healthy.
• raises the error/exception when MeiliSearch is unhealthy. This makes the program stops.

Option C (mix of both) ♥️

health():

• returns true when MeiliSearch is healthy.
• raises the error/exception when MeiliSearch is unhealthy. This makes the program stops.

is_healthy():

• returns true when MeiliSearch is healthy.
• returns false when MeiliSearch is unhealthy (an error is caught)

📢 Let's the vote begin with the right emoji linked to each option! Of course, feel free to argue your point of view and to suggest another option!

---

TODO:

• meilisearch-dart
• meilisearch-dotnet
• meilisearch-go
• meilisearch-java
• meilisearch-js
• meilisearch-php
• meilisearch-python
• meilisearch-ruby
• meilisearch-rust
• meilisearch-swift

[curquiza]

The C option was chosen! 🚀

[curquiza]

This issue was opened before the release of the v0.20.0 and the changes applied to the health route. Now, the /health route returns 200 with a body { "status": "available" } if reachable.
Should the health() method return only true or the body returned by MeiliSearch?

I personally would say the health() method should return the body since the is_healthy() is already the "boolean" method that returns true if reachable.

[bidoubiwa]

I agree. I would still go for option ❤️:
health()
-> success returns body with success { "status": "available" }
-> fail: error thrown.

is_healthy()
-> success true
-> fail: false

My only question is
-> fail: error thrown.

Is the error MeilISearchCommunicationError ? I know it is the name of the error when trying to query when MS is down, multiple SDK's use that error, It could be the one we use for unhealthy.
Should we standarized this error or leave the choice to the appreciation of the SDK?

[curquiza]

As for any other methods provided by the SDKs, the error thrown by health() should be the error that is "naturally" raised. No need to catch it in the health() method, the error is going to be thrown during the code execution -> the users need to know what is the exact error, that's why they use health() instead of is_healthy()

Update: I removed the "caught" word in the health() method description that made the things confusing

[alallema]

For golang, on this issue, I'm wondering if we have to change the Health().Get() method.
The convention in Go is to return (value, error), and if error != nil then value is (or may be) invalid. If an error is not nil you can use log.Fatal(err) to stop your program and throw the error.
Currently, the prototype of the function is:

func (c clientHealth) Get() error;

I guess that we have two solutions:

• Leave the code as-is. If the function returns an error, so Health().Get() is False.
• Change the prototype function for having the error and the boolean value too:

func (c clientHealth) Get() (resp bool, err error);

In any case, I would say that having two methods for golang could be unjustified.