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 #2994] [BUG]: Native Embedder Bug: Successful Indexing Despite Error Message #1915

New Issue
Closed
opened 2026-02-22 18:27:13 -05:00 by yindo · 1 comment
yindo commented 2026-02-22 18:27:13 -05:00
Owner
Copy Link
Copy Source

Originally created by @Peterson047 on GitHub (Jan 20, 2025).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/2994

How are you running AnythingLLM?

Docker (VM Google Cloud 4vCPU - 4GB RAM)

What happened?

For several days, I’ve noticed a peculiar “bug” on the platform. When I upload a relatively large file in terms of word count, the native embedding model throws an error like:
SyntaxError: Unexpected token 's', "stream timeout" is not valid JSON.

This error suggests that the process failed and that the file wasn’t embedded. However, upon refreshing the page, the file magically appears as embedded.

While using the platform via the interface, this wasn’t a major issue—I could simply try again. However, when using the API, the same error occurred, and the connection was closed, preventing the process from completing successfully.

After much analysis, I suspected the issue might be related to the processor. I’m running the system on a 4-core VM in GCP. Previously, the same VM used to crash the container when I also ran the embedded vector database. I resolved that issue by hosting the files on Pinecone.

While monitoring the server's CPU usage, I noticed that even after the mentioned error, CPU usage remained high. This led me to discover that despite the interface or API returning an error, the file-to-vector conversion process continued running. That’s why, after refreshing the page, the file was already embedded.

My question:

What would be the best solution to address this issue?

  • Increase the VM’s resources?
  • Use an embedding service like Cohere, which provides dedicated support, similar to how I resolved the vector database issue with Pinecone?
  • Adopt a newer version of the embedding model available in the latest builds of AnythingLLM?

I’m working on a solution that will operate in automated routines. At certain intervals, the system will automatically send documents to the Workspace and pin them for user queries. However, this bug is creating challenges for implementing this functionality.

I appreciate any feedback or suggestions!

Are there known steps to reproduce?

No response

Originally created by @Peterson047 on GitHub (Jan 20, 2025). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/2994 ### How are you running AnythingLLM? Docker (VM Google Cloud 4vCPU - 4GB RAM) ### What happened? For several days, I’ve noticed a peculiar “bug” on the platform. When I upload a relatively large file in terms of word count, the native embedding model throws an error like: **SyntaxError: Unexpected token 's', "stream timeout" is not valid JSON.** This error suggests that the process failed and that the file wasn’t embedded. However, upon refreshing the page, the file magically appears as embedded. While using the platform via the interface, this wasn’t a major issue—I could simply try again. However, when using the API, the same error occurred, and the connection was closed, preventing the process from completing successfully. After much analysis, I suspected the issue might be related to the processor. I’m running the system on a 4-core VM in GCP. Previously, the same VM used to crash the container when I also ran the embedded vector database. I resolved that issue by hosting the files on Pinecone. While monitoring the server's CPU usage, I noticed that even after the mentioned error, CPU usage remained high. This led me to discover that despite the interface or API returning an error, the file-to-vector conversion process continued running. That’s why, after refreshing the page, the file was already embedded. ### My question: What would be the best solution to address this issue? - **Increase the VM’s resources?** - **Use an embedding service like Cohere, which provides dedicated support, similar to how I resolved the vector database issue with Pinecone?** - **Adopt a newer version of the embedding model available in the latest builds of AnythingLLM?** I’m working on a solution that will operate in automated routines. At certain intervals, the system will automatically send documents to the Workspace and pin them for user queries. However, this bug is creating challenges for implementing this functionality. I appreciate any feedback or suggestions! ### Are there known steps to reproduce? _No response_
yindo added the possible bug label 2026-02-22 18:27:13 -05:00
yindo closed this issue 2026-02-22 18:27:13 -05:00
yindo commented 2026-02-22 18:27:13 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Jan 21, 2025):

(VM Google Cloud 4vCPU - 4GB RAM)

This is probably the issue. Depending on the content size this is most certainly the issue. One way to verify is to stream the logs from the container and watch as it iterates over each chunk. If the service OOM's the logs will just stop. You can also htop and see memory/SWAP probably increase with each chunk.

We do a bit of memory optimization here with this:
https://github.com/Mintplex-Labs/anything-llm/blob/7e10205df61c92e155f4bcdbc7dbd7a38d3c182b/server/utils/EmbeddingEngines/native/index.js#L146-L180

But its still a memory-intensive process - it is the root cause for this on Hosted https://docs.anythingllm.com/cloud/limitations#limited-capacity-for-built-in-embedder

The only solutions are:

  • Bigger machine
  • Offload embeddings to external service (local or cloud)

Its simply a memory intensive process to go run an ONNX model to generate embeddings on a large corpus of text.

@timothycarambat commented on GitHub (Jan 21, 2025): > (VM Google Cloud 4vCPU - 4GB RAM) This is probably the issue. Depending on the content size this is most certainly the issue. One way to verify is to stream the logs from the container and watch as it iterates over each chunk. If the service OOM's the logs will just _stop_. You can also `htop` and see memory/SWAP probably increase with each chunk. We do a bit of memory optimization here with this: https://github.com/Mintplex-Labs/anything-llm/blob/7e10205df61c92e155f4bcdbc7dbd7a38d3c182b/server/utils/EmbeddingEngines/native/index.js#L146-L180 But its still a memory-intensive process - it is the root cause for this on Hosted https://docs.anythingllm.com/cloud/limitations#limited-capacity-for-built-in-embedder The only solutions are: - Bigger machine - Offload embeddings to external service (local or cloud) Its simply a memory intensive process to go run an ONNX model to generate embeddings on a large corpus of text.
yindo changed title from [BUG]: Native Embedder Bug: Successful Indexing Despite Error Message to [GH-ISSUE #2994] [BUG]: Native Embedder Bug: Successful Indexing Despite Error Message 2026-06-05 14:43:26 -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 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#1915
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?