Bug Feedback: v1.13.0 Knowledge Retrieval Node Metadata Filtering - 'Variables' Ineffective, 'Constants' Work Normally - Source Code Root Cause Analysis

Problem Description

In Dify v1.13.0 self-deployed with Docker, the metadata filtering function of the knowledge retrieval node has the following anomaly:

  • :white_check_mark: Setting the filter value as a constant: Filters normally, results meet expectations.

  • :cross_mark: Setting the filter value as a variable (referencing the output of other nodes): Filtering completely fails, results are incorrect.

This function worked perfectly in v1.11.4, but this issue appeared after upgrading to v1.13.0.


Root Cause (Source Code Analysis)

By analyzing the v1.13.0 source code, it’s evident that v1.13.0 refactored the knowledge retrieval node. The code migrated from the old path:

Code

api/core/workflow/nodes/knowledge_retrieval/

to the new path:

Code

api/dify_graph/nodes/knowledge_retrieval/

The problem lies in the _extract_variable_selector_to_variable_mapping method. This method’s purpose is to inform the graph engine “which upstream variables this node depends on,” so the engine can inject variable values into the variable_pool (variable pool) in advance.

However, in the new version of the code, this method only registers query variables, completely omitting variable references within the metadata filtering conditions:

Python

# api/dify_graph/nodes/knowledge_retrieval/knowledge_retrieval_node.py
@classmethod
def _extract_variable_selector_to_variable_mapping(cls, *, graph_config, node_id, node_data):
    typed_node_data = KnowledgeRetrievalNodeData.model_validate(node_data)

    variable_mapping = {}
    if typed_node_data.query_variable_selector:
        variable_mapping[node_id + ".query"] = typed_node_data.query_variable_selector
    if typed_node_data.query_attachment_selector:
        variable_mapping[node_id + ".queryAttachment"] = typed_node_data.query_attachment_selector

    # ❌ This completely fails to handle variable references in metadata_filtering_conditions!
    return variable_mapping

This leads to _resolve_metadata_filtering_conditions() failing to find the corresponding variable in the variable_pool when variable_pool.convert_template("{{#node_id.var#}}") is called at runtime, causing the filtering condition to become ineffective.

The reason constants work normally is that constant values (e.g., "abc") do not have {{#...#}} placeholders in the template during convert_template, so they are returned as-is and do not rely on the variable pool at all.


Execution Flow Comparison

Constant Variable
Storage Format \"abc\" \"{{#start.my_var#}}\"
Depends on Variable Pool No, used directly Yes, retrieves value from pool at runtime
Requires Pre-registration No Yes, must be registered in _extract_variable_selector_to_variable_mapping
v1.13.0 Result :white_check_mark: Normal :cross_mark: Failed

Suggested Fix

In the _extract_variable_selector_to_variable_mapping method, add the registration logic for variable references within metadata_filtering_conditions. Parse the {{#...#}} template in each condition.value and add the corresponding variables to variable_mapping.


Environment Information

  • Dify Version: v1.13.0 (Docker self-deployed)

  • Version Comparison: v1.11.4 normal, v1.13.0 abnormal

  • Problem Path: api/dify_graph/nodes/knowledge_retrieval/knowledge_retrieval_node.py


Hope the official team can fix this soon, thank you!

我也遇到了相同的问题,版本也是1.13.0,希望官方能尽快修复