Failed to connect to Meilisearch: No connection adapters were found for 'localhost:7700/version'

[Zhimin-arya]

Bug description:

When I apply the semantic search following steps at https://www.meilisearch.com/docs/guides/ai/langchain#requirements, and failed at below codes:

vector_store = Meilisearch.from_documents(documents=documents, embedding=embeddings, embedders=embedders, embedder_name=embedder_name)

Failed with error: "Failed to connect to Meilisearch: No connection adapters were found for 'localhost:7700/version'"

The problem was caused by requests.get(url) function if url doesn't start with 'http://'
My current workaround is to add one line to meilisearch.py within function "_create_client()":

if not client:
    url = url or get_from_env("url", "MEILI_HTTP_ADDR")
    if url.startswith('localhost'): url = 'http://' + url # Insert here

I also tried to change MEILI_HTTP_ADDR="localhost:7700" to MEILI_HTTP_ADDR="http://localhost:7700", however, the meilisearch will fail to launch.

Meilisearch version:
1.8.1

Additional context
macOS: sonoma 14.1
chip: M3

[curquiza]

Hello @Zhimin-arya
Sorry for the delay

Connection error means you did not reach Meilisearch, it's not an issue on Meilisearch itself since you don't even reach it.
Can you check you can reach it with curl command?
Did you manage to start Meilisearch without any issue?

[Zhimin-arya]

Hello @Zhimin-arya Sorry for the delay

Connection error means you did not reach Meilisearch, it's not an issue on Meilisearch itself since you don't even reach it. Can you check you can reach it with curl command? Did you manage to start Meilisearch without any issue?

I have added the solution for the problem at the end of 1st comment. I think it is something related to meilisearch code, cause the url without 'http://' prefix will fail to connect the adaptor.

[curquiza]

Hello @Zhimin-arya
I'm really sorry for the late answer

I talked with the team and we don't plan to assume an protocol when it's missing

Should we assume a http or a https prefix when missing?
We need to think about the future as well: what if we someday add unix sockets or another RPC transport, why should we default to the http scheme?

However, we can improve the error message to better guide our users and avoid the frustration you had! I close this issue in favor of #4811