Open WebUI Community Reports Memory Reindexing Bypasses Concurrency Limits, Potentially Flooding Embedding Endpoints

Open WebUI’s memory vector reindexing process has a concurrency control gap. A report filed on October 11 covers v0.12.0, Docker, and Ubuntu Server 24.04: after setting the embedding concurrency limit to 2 and running “Reindex Knowledge and Memory Vectors,” the user saw dense bursts of requests for memory data. The attached inference endpoint logs show multiple requests receiving HTTP 429 responses within the same second. The report says knowledge documents respect the limit, while memory reindexing does not. Community report

The official documentation defines RAG_EMBEDDING_CONCURRENT_REQUESTS as the maximum number of simultaneous requests to the asynchronous embedding API. A positive integer should throttle requests through a semaphore; 0 means unlimited concurrency. This setting differs from the batch size, which controls how much text each request contains. Administrators who limit the amount of data in each batch should also verify how many requests are actually sent at once. Configuration documentation

On October 12, another contributor added a function-level reproduction on a development branch. In a test using one user’s 10 memories, the OpenAI embedding path, and a batch size of 1, peak concurrency during memory reindexing remained at 10 when the limit was set to 1 or 2. Passing the same text as a single batch to the wrapper function kept concurrency at 1 and 2, respectively. The contributor’s analysis points to the memory flow passing individual strings through asyncio.gather, while the wrapper applies rate limiting only to list inputs. This is still the contributor’s analysis and awaits confirmation from maintainers. Reproduction and analysis

Technically, this means whether rate limiting takes effect may depend on how the function is called. In deployments sharing an embedding service, reindexing could create a burst of load. However, this does not establish that all backends are affected, and there is no evidence that existing vectors have been corrupted. The supplementary tests used a mocked endpoint and database substitutes; they were not full Docker or interface tests. Testing limitations

As of this review, the proposed fix is to route memory text through the existing list/batch path. The issue is not yet linked to a fix PR. Engineering teams should monitor actual concurrency and 429 rates during reindexing. Follow-up validation should cover vector ordering, content prefixes, user context, and both limited and unlimited concurrency settings. Proposed fix