sys.files not populated when files are included

[william-schaller]

Hi, thanks a lot for this module, it's been a great help!

I'm trying to use the new file upload feature but facing an issue. I added some extra logging to the provider to try and debug what is going wrong but have hit a wall. I am using a Chatflow which should be accepting the default sys.files input variable. When the provider sends the request to the Dify API it does contain the successfully uploaded file:

{
      "inputs": {},
      "query": "summarise this document",
      "response_mode": "streaming",
      "user": "will",
      "files": [ // Correctly populated here
        {
          "type": "document",
          "transfer_method": "local_file",
          "upload_file_id": "bbe7e..."
        }
      ]
}

However it seems to get silently dropped by the next step, when the workflow starts, and is not included as sys.files:

{
      "event": "workflow_started",
      "conversation_id": "4e3e3...",
      "message_id": "0a318...",
      "task_id": "4e270...",
      "created_at": 1773749155,
      "workflow_run_id": "26ec8...",
      "data": {
        "id": "26ec8...",
        "workflow_id": "2bf9f...",
        "created_at": 1773749155,
        "inputs": {
          "sys.files": [], // Empty here
          "sys.user_id": "will",
          "sys.app_id": "d33e5...",
          "sys.workflow_id": "2bf9f...",
          "sys.workflow_run_id": "26ec8...",
          "sys.query": "summarise this document",
          "sys.dialogue_count": 1
        }
      }
}

Does anyone know how to address this? Thanks in advance 🙂

[warmwind]

@claude can you take a look?

[claude]

Claude finished @warmwind's task in 2m 2s —— View job

---

Investigation: sys.files not populated when files are included

• Read codebase and gather context
• Analyze file upload handling
• Identify root cause
• Provide recommendations

---

Analysis

After reviewing the provider code, the provider itself is behaving correctly — it uploads the file to Dify and includes it in the top-level files field of the request body, exactly as the Dify API specifies.

The empty sys.files issue is almost certainly caused by one of the following:

1. File Upload not enabled in the Chatflow (most likely cause)

In Dify, for sys.files to be populated in a Chatflow, the Chatflow must have the "File Upload" feature explicitly enabled in the app settings:

Dify App → Features → Enable File Upload

Without this, Dify accepts the files parameter in the API without error, but silently ignores it — sys.files stays empty. This matches exactly what the issue describes.

2. Dify version behaviour

Older Dify versions may not support sys.files population via the API's files field. Ensure you're on a recent Dify version.

---

Provider-side observations (minor issues unrelated to the reported bug)

While reviewing the code, I noticed two things worth flagging:

a) Files from all messages are re-uploaded on every turn (stream-parser.ts:347-394)

extractFileAttachments iterates over all messages, not just the latest user message. In a multi-turn conversation, files from previous turns will be re-uploaded and re-sent on every subsequent request. This is wasteful and could cause unexpected behaviour.

b) image-type content parts are not handled

The AI SDK v2 can represent images as { type: "image", ... } content parts, but extractFileAttachments only checks for type === "file". Images sent via type: "image" will be silently dropped.

---

Recommended fix for (a): Only extract files from the latest user message

In dify-chat-language-model.ts:477, the call is:

const files = await extractFileAttachments(messages, userId, ...);

This should be scoped to only the most-recent user message(s). Something like:

// Only extract files from the current (new) turn's messages
const currentMessages = messages.slice(startIndex);
const files = await extractFileAttachments(currentMessages, userId, ...);

But startIndex is computed inside buildQuery — it would need to be exposed or computed earlier.

---

Summary

For @william-schaller: the fix is on the Dify side — enable File Upload in your Chatflow's features. The provider is sending the right payload.

For maintainers: the two minor provider issues above (#a and #b) are worth addressing in a follow-up.

[william-schaller]

That was indeed the problem, thanks!