Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #5127] [BUG]: LMStudio (and other custom providers) shows "--loading available models--" indefinitely when connection fails — no error feedback #4931

New Issue
Closed
opened 2026-06-05 14:50:57 -04:00 by yindo · 1 comment
yindo commented 2026-06-05 14:50:57 -04:00
Owner
Copy Link
Copy Source

Originally created by @elevatingcreativity on GitHub (Mar 3, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5127

How are you running AnythingLLM?

Docker (local)

What happened?

Description

When the LMStudio model listing request fails (connection refused, server
unreachable, wrong URL, remote server not bound to a network interface) or
returns an empty list, the model selection dropdown shows --loading available
models-- indefinitely with no error message or indication that anything went
wrong.

This makes it impossible for users to distinguish between:

  • The request is still in flight (actually loading)
  • The request completed but failed (connection error, wrong URL, server not
    running)
  • The request succeeded but returned zero models (no model loaded in LMStudio's
    server tab)

Root Cause

In LMStudioModelSelection (and the equivalent embedding component), the render
condition is:

if (loading || customModels.length === 0) {
// shows "--loading available models--"
}

Both the "in-progress" state and the "failed/empty" state render the same
--loading available models-- text. There is no separate handling for the
post-load empty case, and no error message is surfaced to the user.

Impact

This has caused repeated user confusion across multiple closed issues where
users spent significant time debugging their LMStudio setup, network
configuration, or AnythingLLM installation — not realizing the UI was silently
swallowing a connection error:

  • #3519 — LMStudio models not appearing in dropdown
  • #1338 — Stuck at "--loading available models--"
  • #3656 — Cannot connect to Ollama, same stuck UI
  • #1681 — Unable to connect to LMStudio on openSUSE
  • #4572 — LMStudio stopped working after upgrade

Expected Behavior

After the model listing request completes (whether successful or not):

  • If models are returned → show the dropdown as normal
  • If the request failed or returned empty → show a clear error/status message
    such as "Could not reach LMStudio — check the URL and ensure the server is
    running" rather than the loading placeholder

Environment

  • AnythingLLM v1.11.0
  • LMStudio 0.4.4
  • Affects both LLM provider selection and embedding provider selection
    components

Note

A PR fixing this UI behavior will be submitted shortly.

Are there known steps to reproduce?

Steps to Reproduce

  1. Open AnythingLLM and navigate to Settings → LLM Preference
  2. Select LMStudio as the provider
  3. In the LM Studio Base URL field, enter a URL that is either:
    - A remote LMStudio instance that has not enabled "Allow connections from
    local network" in its server settings (i.e. still bound to 127.0.0.1 only), or
    - Any URL where LMStudio is unreachable (wrong IP, server not started, Docker
    localhost resolving to the container instead of the host)
  4. Observe the LM Studio Model dropdown

Expected: An error message indicating the server could not be reached, prompting
the user to check their URL or LMStudio configuration.

Actual: The dropdown displays --loading available models-- indefinitely. There
is no error, no timeout message, and no indication the request has already
completed and failed. The UI appears identical to a normal in-progress loading
state.

Originally created by @elevatingcreativity on GitHub (Mar 3, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5127 ### How are you running AnythingLLM? Docker (local) ### What happened? **Description** When the LMStudio model listing request fails (connection refused, server unreachable, wrong URL, remote server not bound to a network interface) or returns an empty list, the model selection dropdown shows --loading available models-- indefinitely with no error message or indication that anything went wrong. This makes it impossible for users to distinguish between: - The request is still in flight (actually loading) - The request completed but failed (connection error, wrong URL, server not running) - The request succeeded but returned zero models (no model loaded in LMStudio's server tab) **Root Cause** In LMStudioModelSelection (and the equivalent embedding component), the render condition is: if (loading || customModels.length === 0) { // shows "--loading available models--" } Both the "in-progress" state and the "failed/empty" state render the same --loading available models-- text. There is no separate handling for the post-load empty case, and no error message is surfaced to the user. **Impact** This has caused repeated user confusion across multiple closed issues where users spent significant time debugging their LMStudio setup, network configuration, or AnythingLLM installation — not realizing the UI was silently swallowing a connection error: - #3519 — LMStudio models not appearing in dropdown - #1338 — Stuck at "--loading available models--" - #3656 — Cannot connect to Ollama, same stuck UI - #1681 — Unable to connect to LMStudio on openSUSE - #4572 — LMStudio stopped working after upgrade **Expected Behavior** After the model listing request completes (whether successful or not): - If models are returned → show the dropdown as normal - If the request failed or returned empty → show a clear error/status message such as "Could not reach LMStudio — check the URL and ensure the server is running" rather than the loading placeholder **Environment** - AnythingLLM v1.11.0 - LMStudio 0.4.4 - Affects both LLM provider selection and embedding provider selection components **Note** A PR fixing this UI behavior will be submitted shortly. ### Are there known steps to reproduce? **Steps to Reproduce** 1. Open AnythingLLM and navigate to Settings → LLM Preference 2. Select LMStudio as the provider 3. In the LM Studio Base URL field, enter a URL that is either: - A remote LMStudio instance that has not enabled "Allow connections from local network" in its server settings (i.e. still bound to 127.0.0.1 only), or - Any URL where LMStudio is unreachable (wrong IP, server not started, Docker localhost resolving to the container instead of the host) 4. Observe the LM Studio Model dropdown Expected: An error message indicating the server could not be reached, prompting the user to check their URL or LMStudio configuration. Actual: The dropdown displays --loading available models-- indefinitely. There is no error, no timeout message, and no indication the request has already completed and failed. The UI appears identical to a normal in-progress loading state.
yindo added the possible bug label 2026-06-05 14:50:57 -04:00
yindo closed this issue 2026-06-05 14:50:57 -04:00
yindo commented 2026-06-05 14:50:57 -04:00
Author
Owner
Copy Link
Copy Source

@elevatingcreativity commented on GitHub (Mar 3, 2026):

Further elaboration and fix

I ran into this problem personally and spent several days trying to diagnose it.
My LMStudio instance was running and responding correctly when tested directly
(via curl), but AnythingLLM just showed --loading available models--
indefinitely with no feedback. The root cause turned out to be that LMStudio's
"Allow connections from local network" setting was disabled — so it was only
bound to 127.0.0.1 and rejecting connections from other machines. Because the UI
gave no indication that the request had already completed and failed, there was
nothing to point me toward the actual problem.

This PR separates the silent failure state from the loading state. Previously,
both "request in progress" and "request completed but returned nothing" showed
identical placeholder text. The fix introduces three distinct states:

  • While the request is in flight → --loading available models-- (unchanged)
  • After the request completes with no models → No models found in the dropdown,
    plus a red message below: "Could not reach LMStudio. Verify the URL is correct
    and the LMStudio server is running and accessible."
  • No URL entered yet → Enter LM Studio URL first (unchanged)

The fix applies to both the LLM provider and embedding provider selection
components. Screenshot below shows the new error state.

Note: Two related timeout issues were identified during investigation but are
not addressed here — the auto-detect function uses a 2-second timeout that may
be too short for slower networks, and the manual URL fetch has no timeout at
all. These will be tracked separately.

Image
<!-- gh-comment-id:3994891966 --> @elevatingcreativity commented on GitHub (Mar 3, 2026): Further elaboration and fix I ran into this problem personally and spent several days trying to diagnose it. My LMStudio instance was running and responding correctly when tested directly (via curl), but AnythingLLM just showed --loading available models-- indefinitely with no feedback. The root cause turned out to be that LMStudio's "Allow connections from local network" setting was disabled — so it was only bound to 127.0.0.1 and rejecting connections from other machines. Because the UI gave no indication that the request had already completed and failed, there was nothing to point me toward the actual problem. This PR separates the silent failure state from the loading state. Previously, both "request in progress" and "request completed but returned nothing" showed identical placeholder text. The fix introduces three distinct states: - While the request is in flight → --loading available models-- (unchanged) - After the request completes with no models → No models found in the dropdown, plus a red message below: "Could not reach LMStudio. Verify the URL is correct and the LMStudio server is running and accessible." - No URL entered yet → Enter LM Studio URL first (unchanged) The fix applies to both the LLM provider and embedding provider selection components. Screenshot below shows the new error state. Note: Two related timeout issues were identified during investigation but are not addressed here — the auto-detect function uses a 2-second timeout that may be too short for slower networks, and the manual URL fetch has no timeout at all. These will be tracked separately. <img width="782" height="391" alt="Image" src="https://github.com/user-attachments/assets/b2235405-c98f-4fdb-8d79-877f5ae8d54c" />
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label possible bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#4931
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?