First image download fails with 404 on first Chatflow execution after Dify container startup

[Hyo-munshin]

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.11.4

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

1. Upload a document containing images into a Knowledge Base.
2. During chunk generation, the chunks contain image URLs such as:

![image](http://api:5001/files/<file_id>/file-preview)

3. Perform knowledge retrieval which returns multiple chunks containing image URLs.
4. Iterate over all image URLs in Chatflow and convert them into Dify file objects using a simple custom dify plugin, which only utilizing create_image_message() interface, like:

class ImageUrlToFile(Tool):
  def _invoke(self, tool_parameters: dict[str, Any]) -> Generator[ToolInvokeMessage]:
      image_url = tool_parameters.get("image_url", "")
      yield self.create_image_message(image_url)

The Chatflow workflow is: knowledge retrieval → URL filtering using a regular expression → converting the URLs to files via a plugin → response.

5. Restart the Dify Docker containers.
6. Execute the Chatflow for the first time after startup.

✔️ Expected Behavior

All image URLs should be successfully downloaded and converted into Dify file objects during the first Chatflow execution.

❌ Actual Behavior

During the first Chatflow execution after container startup:

• The first image URL fails with the error:

 Failed to download image: http://api:5001/files/<file_id>/file-preview?timestamp=xxxxx&nonce=xxxxx&sign=xxxx:
Client error '404 Not Found' for url ' http://api:5001/files/<file_id>/file-preview?timestamp=xxxxx&nonce=xxxxx&sign=xxxx'

• All subsequent images in the same execution succeed.
• Tried to catch the error in custom pulgin, but it seems that the error does not from the plugin.

After this first execution:

• Running the same Chatflow again works normally.
• All images download successfully, including the first one.

[dosubot]

Hi @Hyo-munshin! I'm Dosu and I’m helping the dify team.

This looks like a storage initialization race condition that has been reported in similar forms before. The pattern you're seeing (first image fails, subsequent ones succeed) is consistent with a timing issue during container startup.

Root Cause: The storage backend initialization is synchronous but doesn't verify that files are actually accessible after startup. The file preview endpoint directly attempts to load files without any existence check with retry logic - the OpenDAL storage retry only applies to read operations, not the existence check. By the time you make subsequent requests, the storage is fully initialized.

Potential Workarounds:

1. Add a brief delay or health check before running workflows immediately after container startup
2. Ensure your Docker volumes are properly configured - missing volume mounts can cause similar 404 issues
3. Verify your INTERNAL_FILES_URL configuration - in Dify v1.7.1+, INTERNAL_FILES_URL takes precedence over FILES_URL

This appears to be a genuine bug in the startup sequence. As a workaround until a fix is implemented, waiting a few seconds after container startup before executing workflows should avoid the issue.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[Hyo-munshin]

INTERNAL_FILES_URL is set correctly as http://api:5001 and the dify volumes are not modified.
The Chatflow works fine except for the first exectution. A delay and retry at the first execution does not help.