[Bug] variable_name filter not working in GET /conversations/{conversation_id}/variables

[caiyuanhangDicp]

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

Version 1.10.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

Steps to Reproduce

curl -X GET \
  'https://<your-dify-domain>/v1/conversations/<conversation_id>/variables?user=<user_id>&variable_name=citation_details' \
  --header 'Authorization: Bearer <your_app_key>'

The API response returns all conversation variables within the limit rather than filtering by the specified variable name.

Expected Behavior

Only variables with the name citation_details should be returned.

Actual Behavior

The API ignores the variable_name parameter and returns all variables within the page limit.

✔️ Expected Behavior

Expected Behavior

Only variables with the name citation_details should be returned.

❌ Actual Behavior

Actual Behavior

The API ignores the variable_name parameter and returns all variables within the page limit.

[dosubot]

The variable_name filter is not implemented in the GET /conversations/{conversation_id}/variables endpoint. The API only parses pagination parameters (limit and last_id) and does not read or apply variable_name at any stage, which is why all variables are returned regardless of the filter. To support filtering by variable_name, both the request parser and the service query would need to be updated to accept and apply this parameter. You can review the relevant code in the API controller and service layer for details: controller, service. No recent pull requests address this issue.

To reply, just mention @dosu.

---

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

   

[caiyuanhangDicp]

The variable_name filter is not implemented in the GET /conversations/{conversation_id}/variables endpoint. The API only parses pagination parameters (limit and last_id) and does not read or apply variable_name at any stage, which is why all variables are returned regardless of the filter. To support filtering by variable_name, both the request parser and the service query would need to be updated to accept and apply this parameter. You can review the relevant code in the API controller and service layer for details: controller, service. No recent pull requests address this issue.

To reply, just mention @dosu.

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

   

@dosubot
Thanks for the explanation.

Just to clarify — the official Dify API documentation describes variable_name as a supported filter parameter for this endpoint:

https://docs.dify.ai/api-reference/会话管理/获取对话变量

According to the docs, variable_name should filter conversation variables by name, so the current behavior in the self-hosted version is inconsistent with the documented API behavior.

If the feature is not implemented yet, it would be helpful to either:

1. Add support for this filter in the controller + service layer, or
2. Update the documentation so it does not advertise functionality that does not exist.

This parameter is very useful in real workflows, especially when the number of variables grows.
Happy to help test or verify if an implementation becomes available.

Thanks again for looking into this.

[dosubot]

You're absolutely right—there's a clear mismatch between the API documentation (which says variable_name filtering is supported) and the actual implementation, which ignores this parameter and only paginates results. I couldn't find any workarounds, fixes, or plans to address this in the code, issues, pull requests, or documentation.

The best next steps would be to either implement the variable_name filter in both the controller and service layer, or update the docs to reflect the current behavior. Your feedback about the importance of this filter for real workflows is spot on, and your offer to help test is appreciated. If there are any updates or changes, I'll keep you posted.

To reply, just mention @dosu.

---

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

   

[gpyyxall]

The latest version 1.10.1-fix-1 also has this bug