🔨 fix(ToolService): remove userId filter from loadActionSets & Docs…

… Update (#2286)

* fix(ToolService): remove userId filter from `loadActionSets`

* docs: updates to rag_api and docker_override explaining key variable conflicts

api/server/services/ToolService.js

@@ -270,7 +270,6 @@ async function processRequiredActions(client, requiredActions) {
       if (!actionSets.length) {
         actionSets =
           (await loadActionSets({
-            user: client.req.user.id,
             assistant_id: client.req.body.assistant_id,
           })) ?? [];
       }

docker-compose.override.yml.example

@@ -101,6 +101,16 @@ version: '3.4'
 #  rag_api:
 #    image: ghcr.io/danny-avila/librechat-rag-api-dev:latest
 
+# # USE RAG API IMAGE WITH A DIFFERENT OPENAI API KEY FROM THE ENV FILE
+#  rag_api:
+#   environment:
+#     - OPENAI_API_KEY=sk-your_openai_api_key
+
+# # OR, USE A CUSTOM ENVIRONMENT VARIABLE TO AVOID HARD-CODING IT
+#  rag_api:
+#   environment:
+#     - OPENAI_API_KEY=${OPENAI_EMBEDDINGS_API_KEY}
+
 # # ADD OLLAMA
 #  ollama:
 #    image: ollama/ollama:latest

docs/features/rag_api.md

@@ -62,7 +62,13 @@ This contrasts Docker, where is already set in the default `docker-compose.yml`
 
 The RAG API provides several configuration options that can be set using environment variables from an `.env` file accessible to the API. Most of them are optional, asides from the credentials/paths necessary for the provider you configured. In the default setup, only OPENAI_API_KEY is required.
 
-**Important:** When using the default docker setup, the .env file is shared between LibreChat and the RAG API.
+> !!! **Important:** When using the default docker setup, the .env file is shared between LibreChat and the RAG API.
+
+> You will need to utilize the [Docker Compose Override File](../install/configuration/docker_override.md) to set a unique OPENAI_API_KEY value for RAG API, that is different from the one in your `.env` file.
+
+> This may be necessary if you wish to use OpenAI for vector embeddings, but have set `OPENAI_API_KEY=user_provided`
+
+> There is an example for this in `docker-compose.override.yml.example`
 
 Here are some notable configurations:
 

docs/install/configuration/docker_override.md

@@ -96,6 +96,26 @@ After starting your services with the modified configuration, you can verify tha
 By following these steps and considerations, you can easily and safely modify your Docker Compose configuration without altering the original `docker-compose.yml` file, making it simpler to manage and maintain different environments or local customizations.
 
 
+## `deploy-compose.yml`
+
+To use an override file with a non-default Docker Compose file, such as `deploy-compose.yml`, you will have to explicitly specify both files when running Docker Compose commands.
+
+Docker Compose allows you to specify multiple `-f` or `--file` options to include multiple compose files, where settings in later files override or add to those in the first.
+
+The npm commands for "deployed" do this for you but they do not account for override files:
+
+```json
+    "start:deployed": "docker compose -f ./deploy-compose.yml up -d",
+    "stop:deployed": "docker compose -f ./deploy-compose.yml down",
+```
+
+For example, if you use `deploy-compose.yml` as your main Docker Compose configuration and you have an override file named `deploy-compose.override.yml` (you can name the override file whatever you want), you would run Docker Compose commands like so:
+
+```bash
+docker compose -f deploy-compose.yml -f deploy-compose.override.yml pull
+docker compose -f deploy-compose.yml -f deploy-compose.override.yml up
+```
+
 ## MongoDB Authentication
 
 Use of the `docker-compose.override.yml` file allows us to enable explicit authentication for MongoDB.