Upgrading to version 1.13.0 causes the multimodal RAG functionality to become unusable.

[nya1mo]

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.

After upgrading Dify from version 1.11.4 to 1.13.0, when I pass context containing markdown-formatted images retrieved from Knowledge Retrieval to an LLM node, the #context_files# input, which was previously present, disappears, and the LLM can no longer recognize the images.
Reverting to version 1.11.4 resolves this issue.

Is there a way to fix it without downgrading to 1.11.4?

2. Additional context or comments

v1.11.4

Knowledge Retrieval node's OUTPUT

{
  "result": [
    {
      "metadata": {
        "_source": "knowledge",
        "dataset_id": "b2b9c03d-4795-468f-85fe-37d671751d69",
        "dataset_name": "multimodal",
        "document_id": "df9fa22b-da86-44d7-8df7-4387f4043612",
        "document_name": "socrader.txt",
        "data_source_type": "upload_file",
        "segment_id": "25ea6193-80e0-4e25-8955-a328e57da94b",
        "retriever_from": "workflow",
        "score": 0.4501942992210388,
        "child_chunks": [
          {
            "id": "b6a8fbb3-efce-4fc6-ab79-73470a0003eb",
            "content": "![SOCRadar® Cyber Intelligence Inc. | Dark Web Profile: SafePay Ransomware](https://socradar.io/wp-content/uploads/2025/07/dark-web-profile-safepay-ransomware.jpg.webp)",
            "position": 1,
            "score": 0.4501942992210388
          }
        ],
        "segment_hit_count": 3,
        "segment_word_count": 168,
        "segment_position": 1,
        "segment_index_node_hash": "b1e4f8311e26f1406913c08cb5b0623453b7034eeede7377818d5434a27a2c9e",
        "doc_metadata": null,
        "position": 1
      },
      "title": "socrader.txt",
      "files": null,
      "content": "![SOCRadar® Cyber Intelligence Inc. | Dark Web Profile: SafePay Ransomware](https://socradar.io/wp-content/uploads/2025/07/dark-web-profile-safepay-ransomware.jpg.webp)"
    }
  ]
}

LLM node's INPUT

{
  "#context#": "![SOCRadar® Cyber Intelligence Inc. | Dark Web Profile: SafePay Ransomware](https://socradar.io/wp-content/uploads/2025/07/dark-web-profile-safepay-ransomware.jpg.webp)",
  "#context_files#": [
    {
      "dify_model_identity": "__dify__file__",
      "id": "a6bf44a7-7a24-4ba0-88ca-d9f5cd648fe7",
      "tenant_id": "d1fef7e3-22db-4c60-bbd8-39ff46930f5c",
      "type": "image",
      "transfer_method": "local_file",
      "remote_url": "http://api:5001/files/a6bf44a7-7a24-4ba0-88ca-d9f5cd648fe7/file-preview?timestamp=1770949654&nonce=a6ca4d8475d1a208fe968c00937287ae&sign=ufzMJFGpGQzjawpvWbuzs_2xvVRMxxiD-aOnIaSLZKI%3D",
      "related_id": "a6bf44a7-7a24-4ba0-88ca-d9f5cd648fe7",
      "filename": "dark-web-profile-safepay-ransomware.jpg.webp",
      "extension": ".webp",
      "mime_type": "image/webp",
      "size": 73004
    }
  ]
}

v1.13.0

Knowledge Retrieval node's OUTPUT

{
  "result": [
    {
      "metadata": {
        "source": "knowledge",
        "dataset_id": "b2b9c03d-4795-468f-85fe-37d671751d69",
        "dataset_name": "multimodal",
        "document_id": "df9fa22b-da86-44d7-8df7-4387f4043612",
        "document_name": "socrader.txt",
        "data_source_type": "upload_file",
        "segment_id": "25ea6193-80e0-4e25-8955-a328e57da94b",
        "retriever_from": "workflow",
        "score": 0.45014816522598267,
        "child_chunks": [
          {
            "id": "b6a8fbb3-efce-4fc6-ab79-73470a0003eb",
            "content": "![SOCRadar® Cyber Intelligence Inc. | Dark Web Profile: SafePay Ransomware](https://socradar.io/wp-content/uploads/2025/07/dark-web-profile-safepay-ransomware.jpg.webp)",
            "position": 1,
            "score": 0.45014816522598267
          }
        ],
        "segment_hit_count": 7,
        "segment_word_count": 168,
        "segment_position": 1,
        "segment_index_node_hash": "b1e4f8311e26f1406913c08cb5b0623453b7034eeede7377818d5434a27a2c9e",
        "doc_metadata": null,
        "position": 1
      },
      "title": "socrader.txt",
      "files": null,
      "content": "![SOCRadar® Cyber Intelligence Inc. | Dark Web Profile: SafePay Ransomware](https://socradar.io/wp-content/uploads/2025/07/dark-web-profile-safepay-ransomware.jpg.webp)",
      "summary": null
    }
  ]
}

LLM node's INPUT

{
  "#context#": "![SOCRadar® Cyber Intelligence Inc. | Dark Web Profile: SafePay Ransomware](https://socradar.io/wp-content/uploads/2025/07/dark-web-profile-safepay-ransomware.jpg.webp)"
}

[dosubot[bot]]

This appears to be a known regression in v1.13.0. The #context_files# variable is only added to LLM node inputs when the context_files list is non-empty, and after upgrading, the SegmentAttachmentBinding records that link retrieved segments to uploaded files may not be properly recognized.

Recommended fixes (without downgrading):

1. Re-index your knowledge base - Try re-uploading or re-indexing your documents with images to ensure attachment bindings are properly created for v1.13.0's updated handling

2. Use the UI variable picker - When connecting the Knowledge Retrieval output to the LLM node, use the variable picker in the UI rather than manually typing variable names

3. Check for latest patches - v1.13.0 had several multimodal RAG regressions that may be fixed in newer releases

Workaround: If the above doesn't work, you can try adding a Template or Variable Assigner node between Knowledge Retrieval and LLM nodes to explicitly pass the file metadata.

This issue is related to PR #29396 which changed attachment metadata handling between versions. The fix in PR #30210 also addressed some multimodal retrieval issues but may not cover your specific case.

To reply, just mention @dosu.

---

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

   

[nya1mo]

@dosu

Looking at the node.py code you provided, it seems to be traversing _source, but the OUTPUT of the Knowledge Retrieval node appears to return source without an underscore. Has this been changed somewhere?

[dosubot[bot]]

Good catch! You're right to notice that difference. Looking at the code, the field naming is actually consistent - it's just that Pydantic's serialization alias is used to output _source in JSON.

In rag_retrieval_protocol.py, the SourceMetadata class defines:

source: str = Field(
    default="knowledge",
    serialization_alias="_source",
    description="Data source identifier",
)

So internally in Python it's source, but when serialized to JSON (what you see in the OUTPUT), it becomes _source. The LLM node correctly expects _source in the metadata:

if (
    "metadata" in context_dict
    and "_source" in context_dict["metadata"]
    and context_dict["metadata"]["_source"] == "knowledge"
):

So the _source you're seeing in your v1.13.0 Knowledge Retrieval OUTPUT is correct and should match what the LLM node is looking for. The issue with #context_files# disappearing is likely not caused by this field naming - it's more likely related to the attachment binding mechanism I mentioned earlier.

To reply, just mention @dosu.

---

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

   

[nya1mo]

Thanks. Since I'm a beginner and don't understand it well, I'll downgrade to 1.11.4 and use it.