Invalid upload file error in published Advanced Chat app but not in Studio Preview

[masaoy0730]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Hello,
I would like to report a possible bug or ask for advice regarding an Invalid upload file error in an Advanced Chat app.

Environment

• Dify version: 1.14.0
• Deployment: self-hosted with Docker Compose on Ubuntu
• App type: Advanced Chat
• LLM provider: Gemini plugin
• Plugin: langgenius/gemini:0.7.22
• Model tested:
  • gemini-3.1-pro-preview
  • gemini-2.5-flash
• Vector database: Weaviate
• Reranker: Cohere rerank-multilingual-v3.0

Summary of the issue

The workflow works correctly in Studio Preview, but fails when running the published app from the app/web UI.
In Studio Preview:

• The app responds normally.
• Even with Vision enabled, the model can answer questions based on images inside the indexed documents.

In the published app execution:

• The LLM node shows a ! error.
• The worker log shows Invalid upload file.
• The user does not upload any file during the chat.
• The request contains files: [].

What I already tried

I tried the following, but the issue still occurs in the published app:

1. Disabled Vision in the LLM node.
2. Removed all explicit references to sys.files from the LLM node.
3. Disabled app-level file upload.
4. Recreated the LLM node from scratch.
5. Changed the model from gemini-3.1-pro-preview to gemini-2.5-flash.
6. Confirmed that the user request has no uploaded files and files: [].

Current workflow structure

The workflow is basically:
Start -> Knowledge Retrieval -> LLM -> Answer

Important observation

This issue only appears in the published app execution. Studio Preview works normally.
Also, in some API/plugin logs, I noticed many asset fetches for document images, including many .svg, .png, and .jpg files. This made me suspect that the retrieved Knowledge context may contain image/file references from indexed documents. Even when the user uploads no file, the LLM node might be receiving or validating some file-like object from the retrieved context.

Suspected bug

My suspicion is that, in published app execution, when Knowledge Retrieval returns context that includes document image/file references, the LLM node or workflow runtime may validate those references as uploaded files. If one of them is unsupported, empty, invalid, or SVG-related, the workflow fails with: Invalid upload file
This seems inconsistent because:

• The user did not upload a file.
• files is an empty array.
• Vision can be disabled and the error still occurs.
• Studio Preview works correctly.
• The error happens only in published app execution.

Expected behavior

If the user does not upload a file and the LLM node does not explicitly reference sys.files, the workflow should not fail with Invalid upload file.
If the issue is caused by image/file references inside retrieved Knowledge context, Dify should either:

1. ignore unsupported file references when Vision is disabled,
2. convert them to text-only context,
3. show a clearer error indicating which retrieved file or asset is invalid,
4. or behave consistently between Studio Preview and published app execution.

Questions

1. Is this a known issue in Dify 1.14.0?
2. Is there a known difference between Studio Preview and published app execution in how retrieved document images/files are handled?
3. Could SVG or document image assets in Knowledge Retrieval cause Invalid upload file in the LLM node?
4. Is there a recommended way to disable image/file references from retrieved Knowledge context while keeping text retrieval enabled?
5. What logs or database records should I check to identify which file is considered invalid?

I was excited to discover that when using gemini-3.1-pro, Dify can generate answers based not only on the text in Knowledge documents, but also on images contained in those documents.
However, although it works correctly in Studio Preview, it fails with an error when running the published app, so I cannot use this functionality in production.
I would like to be able to use gemini-3.1-pro with Vision enabled for Knowledge documents, even when the end user does not upload any image files during the chat.
Thank you.

2. Additional context or comments

No response

[dosubot[bot]]

Hi @masaoy0730! I'm Dosu and I’m helping the dify team.

Your suspicion is on the right track — this appears to be a file access control issue between Studio Preview and published app execution, not a problem with your workflow configuration.

Root cause: When Knowledge Retrieval returns context containing image references from indexed documents, those images are stored as UploadFile records created by an account user during document indexing [1]. In published app execution, the current user is an end-user, and file access control enforces strict ownership — end-users can only access files they created themselves [2]. The database query for the file returns None, which triggers the Invalid upload file error [3].

Why Studio Preview works: It runs under an account-level execution context where requires_user_ownership = False, so it can access all tenant files regardless of who created them. Published apps enforce requires_user_ownership = True for end-users, blocking access to account-created knowledge base files [4].

This is compounded by a related regression tracked in #32606 — the #context_files# handling in multimodal RAG has had several issues since v1.13.0, including missing SegmentAttachmentBinding records for older documents [5].

Workarounds to try:

1. Re-index your knowledge base — this ensures SegmentAttachmentBinding records are properly created, which may change how files are referenced [5].

2. Use a Code node between Knowledge Retrieval and LLM to extract image URLs and pass them as remote URLs rather than as file references:

   import re
   context = arg1  # from Knowledge Retrieval
   urls = re.findall(r"!\[.*?\]\((.*?)\)", context)
   files = [{"type": "image", "url": url} for url in urls]
   return {"context": context, "files": files}

   [6]

3. Check your Gemini plugin configuration — ensure FILES_URL and INTERNAL_FILES_URL are set correctly in your .env file [7].

Regarding SVG specifically — SVG is listed as a supported image extension [8], so it's not being rejected by file type. The error affects all image types from Knowledge Retrieval equally when accessed by end-users.

This does appear to be a bug — the system should not fail with "Invalid upload file" when the files originate from Knowledge Retrieval context rather than user uploads. You may want to file this as a separate issue if re-indexing doesn't resolve it, since the access control gap for knowledge base context files in published apps hasn't been explicitly addressed yet.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[masaoy0730]

@dosu
Thank you for your reply.

The Knowledge documents I am using contain both text and images. The error occurs when the prompt uses chunks that include images.

I tried the workarounds you suggested:

• Rebuilding the index did not resolve the issue.
• I was not sure how to configure the output of the Code Execution node when using the Python code workaround.
• I checked the .env file and tried setting FILES_URL=http://api:5001, but the behavior did not change.

If this is related to a bug in access control for Knowledge Base context files in the published app, I would like to create a separate issue/discussion for that.

[dosubot[bot]]

Thanks for the update. A couple of things that may help:

On the Code node workaround — to configure the Code node's output, you need to define output variables in the node's "Output Vars" section in the UI. For the image URL extraction workaround, you'd set up something like:

1. Add an input variable (e.g., input_var of type string) and connect it to the Knowledge Retrieval #context# output

2. Define two output variables in the UI: context (type: string) and image_urls (type: array[string])

3. Your code returns a dictionary matching those names:

   import re
   
   def main(input_var: str) -> dict:
       urls = re.findall(r"!\[.*?\]\((.*?)\)", input_var)
       return {
           "context": input_var,
           "image_urls": urls,
       }

4. In the downstream LLM node, use the variable picker to select the Code node's context output instead of the Knowledge Retrieval output directly

[1] [2]

That said, this workaround may still hit the same access control issue since the fundamental problem is in how files are resolved during published app execution.

On the underlying bug — PR #34436 (merged April 2, 2026) fixed IDOR issues in knowledge base file access by adding proper tenant/dataset ownership checks to database queries [3]. This may be related to your issue. If you're on v1.14.0, you might want to check whether upgrading to a newer release that includes this fix resolves the problem.

Filing a separate issue is a good idea — the specific scenario of end-users in published apps being unable to access knowledge base context files with images is worth tracking explicitly, since the existing issues (#32606) focused more on the #context_files# disappearance rather than the access control gap.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[masaoy0730]

Hi Dosu-san,

Thank you for your reply.

I confirmed that the published app works when I use a Code Execution node to remove only the Markdown image links from the context before passing it to the LLM.

However, my goal is to pass the image links from the Knowledge Retrieval output to the LLM so that it can answer questions about the content of the images.

I will create a separate post for this topic.
Thanks.

[masaoy0730]

Hi,
I’ve already opened a separate issue here:
#35783

[francinii]

@dosu
Hi team,

I would like to know if there are any updates on this bug? I am experiencing the same issue in version 1.14.x.

I'd like to check if there is an official fix in any newer version, or clarify where the workaround should actually be implemented.

The workaround suggested by @ibondarenko1 mentions api/services/file_service.py, but in Dify 1.14.x, the architecture has changed and the file access controller logic is located elsewhere.

[dosubot[bot]]

Hi @francinii,

This bug was fixed in May 2026 through two PRs:

• PR #36175 (merged 2026-05-14) — introduced execution-local file access grants so the LLM node can access knowledge base image files during published app execution [1]
• PR #36195 (merged 2026-05-15) — extended the same fix to workflow nodes via DifyRetrieverAttachmentLoader [2]

The fix adds a granted_upload_file_ids allowlist to the FileAccessScope context. During retrieval, when attachment bindings are found, the system calls grant_upload_file_access() to mark those files as accessible within the current execution — without changing persistent ownership. The access controller at api/core/app/file_access/controller.py now checks this allowlist alongside the standard user ownership check [3].

To resolve your issue: Upgrade to a Dify version that includes these PRs (any release after mid-May 2026). The workaround by @ibondarenko1 in Discussion #35783 is no longer necessary with the official fix in place.

You're correct that the architecture changed — the file access control logic is now in api/core/app/file_access/controller.py [4], not api/services/file_service.py.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.