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.

[xXMrNidaXx]

This is a common issue when upgrading RAG systems - multimodal handling often breaks due to embedding dimension mismatches or index schema changes.

Quick troubleshooting steps:

1. Check if your embedding model changed between versions
2. Verify the vector index schema is compatible
3. Try re-indexing a small test dataset

We've seen similar issues in production RAG deployments at RevolutionAI. The fix is usually re-indexing with the new embedding config. If you're dealing with large datasets, consider incremental re-indexing to minimize downtime.

Happy to share more specific debugging steps if you can share your embedding model config!

[xXMrNidaXx]

This looks like a breaking change in how Dify handles multimodal context between versions. A few things that might help:

1. Check the changelog for 1.12.x — there may have been intentional changes to how #context_files# is populated. The metadata structure changed (_source → source), suggesting internal refactoring.

2. Workaround: You might be able to manually extract and pass image URLs to the LLM node using a Code node between Knowledge Retrieval and LLM — parse the markdown image syntax and construct the files array yourself.

3. File an issue if you haven't already — this seems like a regression rather than intended behavior, since the image data is still in the retrieval output but not being forwarded to the LLM input.

We've debugged similar multimodal RAG issues at Revolution AI — often it's a matter of explicit variable mapping after framework upgrades. Let us know if the workaround helps!

[xXMrNidaXx]

This looks like a regression in how context files are passed to the LLM node.

The diff:

• v1.11.4: #context_files# populated with file metadata
• v1.13.0: #context_files# missing entirely

Workaround until fixed:

1. Add a Code node before LLM to manually construct the files array:

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

2. Use HTTP node to fetch images explicitly
   If the LLM needs base64 images rather than URLs.

3. Pin to 1.12.x if available
   Check if the regression exists in intermediate versions.

For the maintainers:
The change likely happened in the workflow executor or context serialization layer. The _source: "knowledge" → source: "knowledge" change suggests a refactor that may have dropped the file attachment logic.

We encounter similar multimodal RAG issues at Revolution AI — definitely worth filing as a bug if not already tracked.

[xXMrNidaXx]

Multimodal RAG breakage after upgrade is frustrating! At RevolutionAI (https://revolutionai.io) we manage Dify deployments.

Quick checks:

1. Config migration:

# Check if new env vars needed
diff .env.example .env

2. Database migration:

docker exec dify-api flask db upgrade

3. Clear cache:

docker exec dify-redis redis-cli FLUSHALL

4. Check model config:

• Vision models need separate config in 1.13+
• Verify multimodal model is still enabled

Rollback if needed:

git checkout v1.12.0
docker-compose up -d --build

What error message are you seeing?

[xXMrNidaXx]

This is a breaking change in 1.13.0 — the #context_files# variable is no longer auto-populated.

Root cause:
1.13.0 changed how file references are extracted from Knowledge Retrieval output. The image URL parsing that populated #context_files# appears to be removed or broken.

Workaround without downgrading:

1. Use Code Node to extract files

import re

def extract_images(context):
    # Extract markdown image URLs
    pattern = r"!\[.*?\]\((https?://.*?)\)"
    urls = re.findall(pattern, context)
    
    return {
        "context": context,
        "image_urls": urls
    }

2. Manually pass images to LLM
In LLM node, add image URLs as separate vision inputs.

3. Use HTTP Request to fetch and attach

[Knowledge Retrieval] → [Code: Extract URLs] → [HTTP: Fetch Images] → [LLM with Vision]

4. Check release notes for migration
There might be a new variable or config needed for multimodal context.

Bug report suggestion:
Open an issue linking this discussion — this seems like a regression that should be fixed, not a feature change.

We run multimodal RAG at Revolution AI — the Code Node extraction is the quickest workaround until this is patched.

[nya1mo]

@xXMrNidaXx

Thank you for your comments and suggestions.
I have created a formal issue to track this regression:
#32606

[nya1mo]

#32006 has been closed.