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

[GH-ISSUE #4093] [BUG]: I am unable to connect a MySQL agent in AnythingLLM #2608

New Issue
Closed
opened 2026-02-22 18:30:26 -05:00 by yindo · 3 comments
yindo commented 2026-02-22 18:30:26 -05:00
Owner
Copy Link
Copy Source

Originally created by @cmosorchestra on GitHub (Jul 3, 2025).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4093

How are you running AnythingLLM?

Docker (local)

What happened?

Summary

I am unable to connect a MySQL agent in AnythingLLM. When I add a SQL agent, it is added to the list, but the connection does not work—there is no error or feedback in the UI. The only clue I have observed that suggests a successful database connection is the appearance of a suffix (such as _T4G6) in the agent’s configuration name. When the connection fails, the suffix is not added to the config name.

This process used to work with the same configuration on a previous database. The only change that occurred between then and now was a permissions issue with MySQL, which has since been fixed according to my tests.

Environment

  • AnythingLLM: latest (Docker)
  • MySQL: 8.0.42-0ubuntu0.22.04.1 (native, on Ubuntu Server 22.04)
  • Ollama: latest (Docker)
  • Model: Llama 3.1
  • Host OS: Ubuntu Server 22.04
  • Docker: 28.2.2, build e6534b4

Steps to Reproduce

  1. Launch AnythingLLM and Ollama in Docker; MySQL runs natively on the host (not in Docker).
  2. Confirm network communication between Docker containers and the host (can connect to MySQL from CLI on host and from within Docker containers).
  3. Go to Agents > Add New Agent > SQL Agent (MySQL).
  4. Enter a valid MySQL connection string (verified to work via CLI): 
    mysql://user:password@host:port/database
    (Note: The host in the connection string is specified as an IP address, not a hostname.)
  5. Click "Add Agent".

Actual Result

  • No error appears in the UI.
  • The agent is added to the list, but the suffix (such as _T4G6) is not added to the config name.
  • In my experience, the only clue that the SQL agent successfully connects to the database is the presence of a suffix in the agent configuration name. When the connection fails, there is no suffix, and no error is shown.
  • I have searched through AnythingLLM backend, frontend, and Docker logs but could not find any clues or relevant errors related to agent creation.

What I Expected

  • The agent should be added (with a suffix in the name), or an error message should display if the connection fails.

Troubleshooting Done

  • This process used to work with the same configuration on a previous database.
  • The only thing that changed in between was a MySQL permissions issue, which has since been fixed (I have verified correct permissions through multiple tests).
  • Verified MySQL credentials by direct CLI access from the Docker host and from inside Docker containers.
  • Tested with different users and databases (all MySQL version 8.0.42).
  • Created a fresh DB with the same MySQL version—same result.
  • Network connectivity between Docker and native MySQL is confirmed working.

Additional Info

  • Example connection string (redacted): 
    mysql://myuser:mypass@192.168.x.x:3306/mydb
    (Note: The host in the connection string is specified as an IP address, not a hostname.)
  • All software is the latest version as of July 2025.

This is blocking use of SQL agents in AnythingLLM. Please advise on further troubleshooting steps, or if this is a regression or a known issue.

Are there known steps to reproduce?

No response

Originally created by @cmosorchestra on GitHub (Jul 3, 2025). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4093 ### How are you running AnythingLLM? Docker (local) ### What happened? ## Summary I am unable to connect a MySQL agent in AnythingLLM. When I add a SQL agent, it is added to the list, but the connection does not work—there is no error or feedback in the UI. The only clue I have observed that suggests a successful database connection is the appearance of a suffix (such as `_T4G6`) in the agent’s configuration name. When the connection fails, the suffix is **not** added to the config name. This process used to work with the same configuration on a previous database. The only change that occurred between then and now was a permissions issue with MySQL, which has since been fixed according to my tests. ## Environment - AnythingLLM: latest (Docker) - MySQL: 8.0.42-0ubuntu0.22.04.1 (native, on Ubuntu Server 22.04) - Ollama: latest (Docker) - Model: Llama 3.1 - Host OS: Ubuntu Server 22.04 - Docker: 28.2.2, build e6534b4 ## Steps to Reproduce 1. Launch AnythingLLM and Ollama in Docker; MySQL runs natively on the host (not in Docker). 2. Confirm network communication between Docker containers and the host (can connect to MySQL from CLI on host and from within Docker containers). 3. Go to Agents > Add New Agent > SQL Agent (MySQL). 4. Enter a valid MySQL connection string (verified to work via CLI): ``` mysql://user:password@host:port/database ``` (Note: The `host` in the connection string is specified as an IP address, not a hostname.) 5. Click "Add Agent". ## Actual Result - No error appears in the UI. - The agent is added to the list, but the suffix (such as `_T4G6`) is **not** added to the config name. - In my experience, the only clue that the SQL agent successfully connects to the database is the presence of a suffix in the agent configuration name. When the connection fails, there is no suffix, and no error is shown. - I have searched through AnythingLLM backend, frontend, and Docker logs but could not find any clues or relevant errors related to agent creation. ## What I Expected - The agent should be added (with a suffix in the name), or an error message should display if the connection fails. ## Troubleshooting Done - This process used to work with the same configuration on a previous database. - The only thing that changed in between was a MySQL permissions issue, which has since been fixed (I have verified correct permissions through multiple tests). - Verified MySQL credentials by direct CLI access from the Docker host and from inside Docker containers. - Tested with different users and databases (all MySQL version 8.0.42). - Created a fresh DB with the same MySQL version—same result. - Network connectivity between Docker and native MySQL is confirmed working. ## Additional Info - Example connection string (redacted): ``` mysql://myuser:mypass@192.168.x.x:3306/mydb ``` (Note: The `host` in the connection string is specified as an IP address, not a hostname.) - All software is the latest version as of July 2025. --- **This is blocking use of SQL agents in AnythingLLM. Please advise on further troubleshooting steps, or if this is a regression or a known issue.** ### Are there known steps to reproduce? _No response_
yindo added the needs info / can't replicate label 2026-02-22 18:30:26 -05:00
yindo closed this issue 2026-02-22 18:30:26 -05:00
yindo commented 2026-02-22 18:30:26 -05:00
Author
Owner
Copy Link
Copy Source

@cmosorchestra commented on GitHub (Jul 5, 2025):

Hello, I'm adding some further debugging information to this issue in the hopes it helps with diagnosis.

To help isolate the problem, I ran a test to confirm connectivity from the Docker network to the host's MySQL server. The test was successful.

Test Steps:
I launched a temporary container with a standard MySQL client on the same Docker network as the AnythingLLM container (allm_default) and attempted to connect to the database using the same credentials.

Command Used:

# Note: 'myuser' is a placeholder for the actual username.
docker run -it --rm --network allm_default mysql:8.0 mysql -h 172.17.0.1 -u myuser -p -D mydatabase

Result:
The connection was successful. I received the mysql> prompt and was able to list the correct tables from my database, confirming the credentials and network path are valid.

Implication:
This result suggests that the underlying infrastructure (Docker networking, host IP address, MySQL bind-address, and user permissions) is all functioning as expected. It appears the issue may be related to how the SQL agent retrieves or initiates its connection using the saved details, as a direct connection from the same network environment works correctly.

Hopefully, this information is helpful for tracking down the cause. Please let me know if there are any other tests I can run to assist.

@cmosorchestra commented on GitHub (Jul 5, 2025): Hello, I'm adding some further debugging information to this issue in the hopes it helps with diagnosis. To help isolate the problem, I ran a test to confirm connectivity from the Docker network to the host's MySQL server. The test was successful. **Test Steps:** I launched a temporary container with a standard MySQL client on the same Docker network as the AnythingLLM container (`allm_default`) and attempted to connect to the database using the same credentials. **Command Used:** ```bash # Note: 'myuser' is a placeholder for the actual username. docker run -it --rm --network allm_default mysql:8.0 mysql -h 172.17.0.1 -u myuser -p -D mydatabase ``` **Result:** The connection was successful. I received the `mysql>` prompt and was able to list the correct tables from my database, confirming the credentials and network path are valid. **Implication:** This result suggests that the underlying infrastructure (Docker networking, host IP address, MySQL `bind-address`, and user permissions) is all functioning as expected. It appears the issue may be related to how the SQL agent retrieves or initiates its connection using the saved details, as a direct connection from the same network environment works correctly. Hopefully, this information is helpful for tracking down the cause. Please let me know if there are any other tests I can run to assist.
yindo commented 2026-02-22 18:30:26 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Jul 7, 2025):

mysql://myuser:mypass@192.168.x.x:3306/mydb

Does this documentation apply here - localhost connections? I would imagine no since you are using local IPs and that should still resolve. Addtionally, in the logs you do not see anything about a failed connection - just that the output of the agent never includes the tool?

@timothycarambat commented on GitHub (Jul 7, 2025): `mysql://myuser:mypass@192.168.x.x:3306/mydb` Does this documentation apply here - [localhost connections](https://docs.anythingllm.com/installation-docker/localhost)? I would imagine no since you are using local IPs and that should still resolve. Addtionally, in the logs you do not see anything about a failed connection - just that the output of the agent never includes the tool?
yindo commented 2026-02-22 18:30:26 -05:00
Author
Owner
Copy Link
Copy Source

@cmosorchestra commented on GitHub (Jul 9, 2025):

I managed to connect to the mySQL database again by:

  • reverting to the bbde71e2cd4b build of anythingLLM
  • using 172.17.0.1:3306 as server endpoint
@cmosorchestra commented on GitHub (Jul 9, 2025): I managed to connect to the mySQL database again by: - reverting to the bbde71e2cd4b build of anythingLLM - using 172.17.0.1:3306 as server endpoint
yindo changed title from [BUG]: I am unable to connect a MySQL agent in AnythingLLM to [GH-ISSUE #4093] [BUG]: I am unable to connect a MySQL agent in AnythingLLM 2026-06-05 14:47:32 -04:00
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 needs info / can't replicate
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#2608
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?