Upload for File Search not Working

[walbercardoso]

What happened?

The Upload for File Search menu option at FileFormWrapper component is not working properly?

When i try to submit a file and ask agent for information, the action to retrieve information is not working:

But when i upload the same file at the Agent Builder, then it works:

Steps to Reproduce

1. Submit file at Upload for File Search menu option at FileFormWrapper component
2. Try to retrieve any information
3. Run File Search dont works
4. Upload the same file at Agent Builder
5. Try to retrieve any information
6. It works

What browsers are you seeing the problem on?

No response

Relevant log output

Screenshots

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

Seems related to your file. It's getting a response from the file search tool, related to the file you uploaded.

[walbercardoso]

Hi @danny-avila the same file works if i upload at the LC Demo. Locally only works i upload the file via Agent Builder. I tried with other file and still can make it work.

I have the lastest update fro the github repo

[aleibovici]

Hey @walbercardoso, I’ve noticed the same issue. It seems like Artifacts might be causing the problem. Can you try disabling it and see if that makes a difference?

[walbercardoso]

Hey @walbercardoso, I’ve noticed the same issue. It seems like Artifacts might be causing the problem. Can you try disabling it and see if that makes a difference?

Hi @aleibovici thank you for your response. Artifacts is already disabled and does not make any differenfe if i enable it or not.

[walbercardoso]

It seems to me that the problem is only with pdf files. If I load .docx, doc, txt and even xls files, the file search works normally.

[walbercardoso]

More details:

Locally:

Demo LC Site:

One caveat is that the Demo LC Site is not updated with the latest git repo update.

[danny-avila]

I think it is updated @fuegovic can confirm. And there were no recent changes to File uploading

[fuegovic]

It's been last updated a couple of days ago. Usually it's updated at least once a week.

[danny-avila]

thanks for confirming!

[walbercardoso]

It's been last updated a couple of days ago. Usually it's updated at least once a week.

Temporary chat is not available at the demo site, so i supposed that.

I really don't know what is the problem

[childotg]

Dear @danny-avila @walbercardoso I have the same issue and probably found the cause.
As a recap, working conditions:

• Created an Agent with File Search
• Uploaded in the Agent Builder some PDFs
• Everything is working

Non-working conditions:

• Created an Agent with File Search
• Files are then uploaded in the chat directly on a session-basis
• The agent cannot access the files

I found, debugging the "rag-api" this message:
root - WARNING - Unauthorized access attempt by user agent_aEG702M4cC5AHOXJUU3Pq to a document with user_id public

This is not showing in the "working conditions" while it's probably blocking the other case.
Can you please confirm this behaviour?
Thank you!

[danny-avila]

@childotg you need to update the RAG API, as that issue was fixed.

Updating Instructions (docker):

# Linux command to Remove all existing images
docker images -a | grep "librechat" | awk '{print $3}' | xargs docker rmi

# Windows Powershell
docker images -a | findstr "librechat" | ForEach-Object { docker rmi $_.Split()[2] }

Then follow the directions here: https://www.librechat.ai/docs/local/docker#update-librechat

[childotg]

I'm actually using ghcr.io/danny-avila/librechat-rag-api-dev-lite:latest from Kubernetes, so it should fetch the right version, isn't it?
Thank you!

[childotg]

@danny-avila it seems LibreChat is not handling the impersonation of the user while going to the RAG through an Agent. If validated, it can be solved either in the client, or in the rag api itself by ignoring, especially in private context, the authentication of the vectorized files.

[zeemy23]

@danny-avila we're seeing this same issue on latest rag image, as well

[danny-avila]

@zeemy23

I'm using the latest image as well without issues:

Including a file just uploaded:

If you're still having trouble, please report an issue, following all the instructions in the form. You may discover the root cause of your issue before even submitting it:
https://github.com/danny-avila/LibreChat/issues/new?template=BUG-REPORT.yml

root@librechat:~/LibreChat# docker images | grep librechat-rag-api
ghcr.io/danny-avila/librechat-rag-api-dev-lite   latest          6550e7ddf180   5 days ago      1.3GB

[walbercardoso]

I'm still having the same problem

[childotg]

@danny-avila @walbercardoso excuse me if I didn't updated you or this discussion but I solved by setting the JWT_SECRET on the RAG-API as well. This was 99% the cause of the problem. Not sure why working directly and not through the agents, but whatever, that fixed!

[parthpat12]

@danny-avila @walbercardoso excuse me if I didn't updated you or this discussion but I solved by setting the JWT_SECRET on the RAG-API as well. This was 99% the cause of the problem. Not sure why working directly and not through the agents, but whatever, that fixed!

Did you set this up in .env file or docker-compose.override.yml? And did you create both new JWT_SECRET and JWT_REFRESH_SECRET?

[childotg]

As an ENV variable, just that one aligned with the value of the one configured in LibreChat

[walbercardoso]

@childotg @parthpat12 i did set both at the .env file not at the docker-compose.override

[walbercardoso]

Could it be something related to meilisearch?

chat-meilisearch | 2025-03-14T18:38:42.827873Z WARN HTTP request{method=GET host="meilisearch:7700" route=/indexes/convos/documents/59ca246a-7d04-4543-b0f6-655869b9ea1f query_parameters= user_agent=node status_code=404 error=Document 59ca246a-7d04-4543-b0f6-655869b9ea1f not found.}: tracing_actix_web::middleware: Error encountered while processing the incoming HTTP request: ResponseError { code: 404, message: "Document 59ca246a-7d04-4543-b0f6-655869b9ea1f not found.", error_code: "document_not_found", error_type: "invalid_request", error_link: "https://docs.meilisearch.com/errors#document_not_found" }
chat-meilisearch | 2025-03-14T18:38:42.828285Z INFO HTTP request{method=GET host="meilisearch:7700" route=/indexes/convos/documents/59ca246a-7d04-4543-b0f6-655869b9ea1f query_parameters= user_agent=node status_code=404 error=Document 59ca246a-7d04-4543-b0f6-655869b9ea1f not found.}: meilisearch: close time.busy=569µs time.idle=439µs

I always see this error above

[walbercardoso]

The problem in my case is that it works the first time I try to retrieve information from the document. But if I continue chatting, the next retrieve doesn't work.

It says, "No files to search"

[walbercardoso]

The problem is in tool_resources. Its empty for some reason at second call.

2025-03-15T00:28:12.140Z debug: [fileSearch] primeFiles - tool_resources: {"file_search":{"files":[{"_id":"67d4c99744cb7fdfe8dd418b","file_id":"52c047ce-9c5c-4e9e-a86f-

second call:

2025-03-15T00:28:12.140Z debug: [fileSearch] primeFiles - tool_resources: {}

I could make it work adding a global cache, but its not the best way to do that.