langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 12:05:30 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

The time-type metadata in the knowledge base cannot be used when using api. #19871

New Issue
Closed
opened 2026-02-21 20:04:40 -05:00 by yindo · 16 comments
yindo commented 2026-02-21 20:04:40 -05:00
Owner
Copy Link
Copy Source

Originally created by @Angelenx on GitHub (Oct 23, 2025).

Originally assigned to: @JohnJyong on GitHub.

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

1.9.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

After I updated Dify from 1.9.1 to version 1.9.2, I used the API to call the knowledge base retrieval function of dify (using the metadata filtering function, the metadata type is Time, and the input value is an integer, that is, the time stamp), which worked normally before the update.

✔️ Expected Behavior

Dify server returns the retrieval result and code 200.

❌ Actual Behavior

It return the error code 400.

Originally created by @Angelenx on GitHub (Oct 23, 2025). Originally assigned to: @JohnJyong on GitHub. ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.9.2 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce After I updated Dify from 1.9.1 to version 1.9.2, I used the API to call the knowledge base retrieval function of dify (using the metadata filtering function, the metadata type is Time, and the input value is an integer, that is, the time stamp), which worked normally before the update. ### ✔️ Expected Behavior Dify server returns the retrieval result and code 200. ### ❌ Actual Behavior It return the error code 400.
yindo added the 🐞 bug label 2026-02-21 20:04:40 -05:00
yindo closed this issue 2026-02-21 20:04:40 -05:00
yindo commented 2026-02-21 20:04:41 -05:00
Author
Owner
Copy Link
Copy Source

@Angelenx commented on GitHub (Oct 23, 2025):

I’m sure the form of the request body is right according to the docs of dify. I checked it carefully.

@Angelenx commented on GitHub (Oct 23, 2025): I’m sure the form of the request body is right according to the docs of dify. I checked it carefully.
yindo commented 2026-02-21 20:04:41 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Oct 23, 2025):

Hi @Angelenx! I'm Dosu and I’m helping the dify team.

Thanks for confirming your request format. Based on recent changes in Dify 1.9.2, stricter validation and type checking for metadata filtering were introduced, especially for dataset configs and metadata conditions. This means that previously accepted formats—like integer timestamps for time-type metadata—may now be rejected if they don't exactly match the expected schema or type (for example, the backend may now require a string or ISO8601 date format instead of a raw integer) see PR #26494.

If you continue to get a 400 error, try converting your time-type metadata value to a string or ISO date format in your request body. Also, double-check that all metadata filtering fields are present and typed exactly as expected by the latest API. If you have access to server logs, reviewing the error details may help pinpoint which field or value is causing the validation failure.

Let me know if you need help with a specific example or want to share your request body for a closer look.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Oct 23, 2025): <!-- Greeting --> Hi @Angelenx! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> Thanks for confirming your request format. Based on recent changes in Dify 1.9.2, stricter validation and type checking for metadata filtering were introduced, especially for dataset configs and metadata conditions. This means that previously accepted formats—like integer timestamps for time-type metadata—may now be rejected if they don't exactly match the expected schema or type (for example, the backend may now require a string or ISO8601 date format instead of a raw integer) [see PR #26494](https://github.com/langgenius/dify/pull/26494). If you continue to get a 400 error, try converting your time-type metadata value to a string or ISO date format in your request body. Also, double-check that all metadata filtering fields are present and typed exactly as expected by the latest API. If you have access to server logs, reviewing the error details may help pinpoint which field or value is causing the validation failure. Let me know if you need help with a specific example or want to share your request body for a closer look. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/10aa6014-e1c2-4fdc-a99d-8580f227e169?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/10aa6014-e1c2-4fdc-a99d-8580f227e169?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/10aa6014-e1c2-4fdc-a99d-8580f227e169?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/10aa6014-e1c2-4fdc-a99d-8580f227e169?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/10aa6014-e1c2-4fdc-a99d-8580f227e169?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/10aa6014-e1c2-4fdc-a99d-8580f227e169?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/10aa6014-e1c2-4fdc-a99d-8580f227e169?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/27358)
yindo commented 2026-02-21 20:04:41 -05:00
Author
Owner
Copy Link
Copy Source

@Angelenx commented on GitHub (Oct 23, 2025):

@dosu
@dosu
Here is my request body:

{
  "query": "{user_query}",
  "retrieval_model": {
    "search_method": "hybrid_search",
    "reranking_enable": false,
    "reranking_mode": null,
    "top_k": 10,
    "score_threshold_enabled": true,
    "score_threshold": 0,
    "weights": 0.7,
    "metadata_filtering_conditions": {
      "logical_operator": "and",
      "conditions": [
        {
          "name": "website_date",
          "comparison_operator": "after",
          "value": {date_start}
        },
       {
          "name": "website_date",
          "comparison_operator": "before",
          "value": {date_end}
        }
      ]
    }
  }
}

{date_start} and {date_end} is raw timestamp which is raw number.
I converted the type of {date_start} to string like "YYYY-MM-DD". And I got another error.

HttpRequestNodeError
Reached maximum retries (0) for URL
@Angelenx commented on GitHub (Oct 23, 2025): @dosu [@dosu](https://go.dosu.dev/dosubot) Here is my request body: ```json { "query": "{user_query}", "retrieval_model": { "search_method": "hybrid_search", "reranking_enable": false, "reranking_mode": null, "top_k": 10, "score_threshold_enabled": true, "score_threshold": 0, "weights": 0.7, "metadata_filtering_conditions": { "logical_operator": "and", "conditions": [ { "name": "website_date", "comparison_operator": "after", "value": {date_start} }, { "name": "website_date", "comparison_operator": "before", "value": {date_end} } ] } } } ``` {date_start} and {date_end} is raw timestamp which is raw number. I converted the type of {date_start} to string like "YYYY-MM-DD". And I got another error. ```bash HttpRequestNodeError Reached maximum retries (0) for URL ```
yindo commented 2026-02-21 20:04:41 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Oct 23, 2025):

Here’s what’s happening:

The 400 error is due to stricter validation in Dify 1.9.2 for metadata filtering. Time-type metadata (like website_date) now requires a specific format—integer timestamps may no longer be accepted, and the backend expects values that match its schema. If you use a float or a string that doesn’t match the expected date format, you’ll get a validation error. The backend expects time-type metadata to be filtered using operators like "is", "before", "after", "is empty", and "is not empty", but the value itself must be correctly typed and formatted—usually as an ISO8601 string or a properly formatted integer, depending on your dataset config and backend expectations. If you see errors about casting floats to integers, make sure your timestamps are integers (no decimal point) or try using ISO8601 date strings if your schema expects that reference.

The HttpRequestNodeError ("Reached maximum retries (0) for URL") is a network/configuration issue, not a request body problem. This happens when the workflow or API client can’t reach the target URL—often because of Docker networking, using localhost inside containers, or firewall/proxy restrictions. To fix this, use your server’s IP address or host.docker.internal in your API URLs and environment variables, and make sure your backend is listening on the correct interface and port. Test connectivity with curl inside your container, and check your Docker/WSL2 network setup reference.

In summary: for the 400 error, double-check your date formats and types; for the network error, review your API endpoint and Docker networking. If you want to share your exact metadata schema or backend logs, I can help you pinpoint the required format for website_date.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Oct 23, 2025): <!-- Answer --> Here’s what’s happening: The 400 error is due to stricter validation in Dify 1.9.2 for metadata filtering. Time-type metadata (like `website_date`) now requires a specific format—integer timestamps may no longer be accepted, and the backend expects values that match its schema. If you use a float or a string that doesn’t match the expected date format, you’ll get a validation error. The backend expects time-type metadata to be filtered using operators like "is", "before", "after", "is empty", and "is not empty", but the value itself must be correctly typed and formatted—usually as an ISO8601 string or a properly formatted integer, depending on your dataset config and backend expectations. If you see errors about casting floats to integers, make sure your timestamps are integers (no decimal point) or try using ISO8601 date strings if your schema expects that [reference](https://github.com/langgenius/dify/issues/19191). The `HttpRequestNodeError` ("Reached maximum retries (0) for URL") is a network/configuration issue, not a request body problem. This happens when the workflow or API client can’t reach the target URL—often because of Docker networking, using `localhost` inside containers, or firewall/proxy restrictions. To fix this, use your server’s IP address or `host.docker.internal` in your API URLs and environment variables, and make sure your backend is listening on the correct interface and port. Test connectivity with `curl` inside your container, and check your Docker/WSL2 network setup [reference](https://github.com/langgenius/dify/discussions/23962). In summary: for the 400 error, double-check your date formats and types; for the network error, review your API endpoint and Docker networking. If you want to share your exact metadata schema or backend logs, I can help you pinpoint the required format for `website_date`. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/ff032fba-351b-4ef0-9dff-7ebf78cc873f?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/ff032fba-351b-4ef0-9dff-7ebf78cc873f?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/ff032fba-351b-4ef0-9dff-7ebf78cc873f?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/ff032fba-351b-4ef0-9dff-7ebf78cc873f?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/ff032fba-351b-4ef0-9dff-7ebf78cc873f?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/ff032fba-351b-4ef0-9dff-7ebf78cc873f?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/ff032fba-351b-4ef0-9dff-7ebf78cc873f?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/27358)
yindo commented 2026-02-21 20:04:41 -05:00
Author
Owner
Copy Link
Copy Source

@Angelenx commented on GitHub (Oct 23, 2025):

@dosu

@dosu @dosu Here is my request body:

{
"query": "{user_query}",
"retrieval_model": {
"search_method": "hybrid_search",
"reranking_enable": false,
"reranking_mode": null,
"top_k": 10,
"score_threshold_enabled": true,
"score_threshold": 0,
"weights": 0.7,
"metadata_filtering_conditions": {
"logical_operator": "and",
"conditions": [
{
"name": "website_date",
"comparison_operator": "after",
"value": {date_start}
},
{
"name": "website_date",
"comparison_operator": "before",
"value": {date_end}
}
]
}
}
}
{date_start} and {date_end} is raw timestamp which is raw number. I converted the type of {date_start} to string like "YYYY-MM-DD". And I got another error.

HttpRequestNodeError
Reached maximum retries (0) for URL

And here is the error body:

{"code":"internal_server_error","message":"(psycopg2.errors.InvalidTextRepresentation) invalid input syntax for type double precision: \"1970-01-01\"\nLINE 3: ...uments.doc_metadata ->> 'date_start') AS FLOAT) > '1970-01-0...\n                                                             ^\n\n[SQL: SELECT documents.id AS documents_id, documents.tenant_id AS documents_tenant_id, documents.dataset_id AS documents_dataset_id, documents.position AS documents_position, documents.data_source_type AS documents_data_source_type, documents.data_source_info AS documents_data_source_info, documents.dataset_process_rule_id AS documents_dataset_process_rule_id, documents.batch AS documents_batch, documents.name AS documents_name, documents.created_from AS documents_created_from, documents.created_by AS documents_created_by, documents.created_api_request_id AS documents_created_api_request_id, documents.created_at AS documents_created_at, documents.processing_started_at AS documents_processing_started_at, documents.file_id AS documents_file_id, documents.word_count AS documents_word_count, documents.parsing_completed_at AS documents_parsing_completed_at, documents.cleaning_completed_at AS documents_cleaning_completed_at, documents.splitting_completed_at AS documents_splitting_completed_at, documents.tokens AS documents_tokens, documents.indexing_latency AS documents_indexing_latency, documents.completed_at AS documents_completed_at, documents.is_paused AS documents_is_paused, documents.paused_by AS documents_paused_by, documents.paused_at AS documents_paused_at, documents.error AS documents_error, documents.stopped_at AS documents_stopped_at, documents.indexing_status AS documents_indexing_status, documents.enabled AS documents_enabled, documents.disabled_at AS documents_disabled_at, documents.disabled_by AS documents_disabled_by, documents.archived AS documents_archived, documents.archived_reason AS documents_archived_reason, documents.archived_by AS documents_archived_by, documents.archived_at AS documents_archived_at, documents.updated_at AS documents_updated_at, documents.doc_type AS documents_doc_type, documents.doc_metadata AS documents_doc_metadata, documents.doc_form AS documents_doc_form, documents.doc_language AS documents_doc_language \nFROM documents \nWHERE documents.dataset_id IN (%(dataset_id_1_1)s::UUID) AND documents.indexing_status = %(indexing_status_1)s AND documents.enabled = true AND documents.archived = false AND CAST((documents.doc_metadata ->> %(doc_metadata_1)s) AS FLOAT) > %(param_1)s AND CAST((documents.doc_metadata ->> %(doc_metadata_2)s) AS FLOAT) < %(param_2)s]\n[parameters: {'indexing_status_1': 'completed', 'doc_metadata_1': 'date_start', 'param_1': '1970-01-01', 'doc_metadata_2': 'date_end', 'param_2': '2025-10-22', 'dataset_id_1_1': 'a67167dc-d89a-4c15-b8ea-c37150f6d4fe'}]\n(Background on this error at: https:\/\/sqlalche.me\/e\/20\/9h9h)","status":500}
@Angelenx commented on GitHub (Oct 23, 2025): @dosu > [@dosu](https://github.com/dosu) [@dosu](https://go.dosu.dev/dosubot) Here is my request body: > > { > "query": "{user_query}", > "retrieval_model": { > "search_method": "hybrid_search", > "reranking_enable": false, > "reranking_mode": null, > "top_k": 10, > "score_threshold_enabled": true, > "score_threshold": 0, > "weights": 0.7, > "metadata_filtering_conditions": { > "logical_operator": "and", > "conditions": [ > { > "name": "website_date", > "comparison_operator": "after", > "value": {date_start} > }, > { > "name": "website_date", > "comparison_operator": "before", > "value": {date_end} > } > ] > } > } > } > {date_start} and {date_end} is raw timestamp which is raw number. I converted the type of {date_start} to string like "YYYY-MM-DD". And I got another error. > > HttpRequestNodeError > Reached maximum retries (0) for URL And here is the error body: ```json {"code":"internal_server_error","message":"(psycopg2.errors.InvalidTextRepresentation) invalid input syntax for type double precision: \"1970-01-01\"\nLINE 3: ...uments.doc_metadata ->> 'date_start') AS FLOAT) > '1970-01-0...\n ^\n\n[SQL: SELECT documents.id AS documents_id, documents.tenant_id AS documents_tenant_id, documents.dataset_id AS documents_dataset_id, documents.position AS documents_position, documents.data_source_type AS documents_data_source_type, documents.data_source_info AS documents_data_source_info, documents.dataset_process_rule_id AS documents_dataset_process_rule_id, documents.batch AS documents_batch, documents.name AS documents_name, documents.created_from AS documents_created_from, documents.created_by AS documents_created_by, documents.created_api_request_id AS documents_created_api_request_id, documents.created_at AS documents_created_at, documents.processing_started_at AS documents_processing_started_at, documents.file_id AS documents_file_id, documents.word_count AS documents_word_count, documents.parsing_completed_at AS documents_parsing_completed_at, documents.cleaning_completed_at AS documents_cleaning_completed_at, documents.splitting_completed_at AS documents_splitting_completed_at, documents.tokens AS documents_tokens, documents.indexing_latency AS documents_indexing_latency, documents.completed_at AS documents_completed_at, documents.is_paused AS documents_is_paused, documents.paused_by AS documents_paused_by, documents.paused_at AS documents_paused_at, documents.error AS documents_error, documents.stopped_at AS documents_stopped_at, documents.indexing_status AS documents_indexing_status, documents.enabled AS documents_enabled, documents.disabled_at AS documents_disabled_at, documents.disabled_by AS documents_disabled_by, documents.archived AS documents_archived, documents.archived_reason AS documents_archived_reason, documents.archived_by AS documents_archived_by, documents.archived_at AS documents_archived_at, documents.updated_at AS documents_updated_at, documents.doc_type AS documents_doc_type, documents.doc_metadata AS documents_doc_metadata, documents.doc_form AS documents_doc_form, documents.doc_language AS documents_doc_language \nFROM documents \nWHERE documents.dataset_id IN (%(dataset_id_1_1)s::UUID) AND documents.indexing_status = %(indexing_status_1)s AND documents.enabled = true AND documents.archived = false AND CAST((documents.doc_metadata ->> %(doc_metadata_1)s) AS FLOAT) > %(param_1)s AND CAST((documents.doc_metadata ->> %(doc_metadata_2)s) AS FLOAT) < %(param_2)s]\n[parameters: {'indexing_status_1': 'completed', 'doc_metadata_1': 'date_start', 'param_1': '1970-01-01', 'doc_metadata_2': 'date_end', 'param_2': '2025-10-22', 'dataset_id_1_1': 'a67167dc-d89a-4c15-b8ea-c37150f6d4fe'}]\n(Background on this error at: https:\/\/sqlalche.me\/e\/20\/9h9h)","status":500} ```
yindo commented 2026-02-21 20:04:41 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Oct 23, 2025):

The error happens because Dify's backend expects numeric timestamps (like Unix epoch integers) for time-type metadata filtering, not date strings. When you send a string like "1970-01-01", the backend tries to cast it to a float in SQL, which fails and causes the error you see.

To fix this, use integer timestamps (e.g., 1700000000) for your website_date filter values in the API request body. Make sure the metadata in your documents is also stored as numeric timestamps—if it's stored as a string, filtering will fail with the current backend logic.

If you need to filter by a date range, convert your start and end dates to Unix timestamps and use those as the values for date_start and date_end. This will match the backend's expectations and avoid the casting error.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Oct 23, 2025): <!-- Answer --> The error happens because Dify's backend expects numeric timestamps (like Unix epoch integers) for time-type metadata filtering, not date strings. When you send a string like "1970-01-01", the backend tries to cast it to a float in SQL, which fails and causes the error you see. To fix this, use integer timestamps (e.g., 1700000000) for your `website_date` filter values in the API request body. Make sure the metadata in your documents is also stored as numeric timestamps—if it's stored as a string, filtering will fail with the current backend logic. If you need to filter by a date range, convert your start and end dates to Unix timestamps and use those as the values for `date_start` and `date_end`. This will match the backend's expectations and avoid the casting error. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/e65f77c8-f06e-442d-9bc6-a8ba2b3c35b8?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/e65f77c8-f06e-442d-9bc6-a8ba2b3c35b8?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/e65f77c8-f06e-442d-9bc6-a8ba2b3c35b8?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/e65f77c8-f06e-442d-9bc6-a8ba2b3c35b8?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/e65f77c8-f06e-442d-9bc6-a8ba2b3c35b8?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/e65f77c8-f06e-442d-9bc6-a8ba2b3c35b8?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/e65f77c8-f06e-442d-9bc6-a8ba2b3c35b8?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/27358)
yindo commented 2026-02-21 20:04:41 -05:00
Author
Owner
Copy Link
Copy Source

@Angelenx commented on GitHub (Oct 23, 2025):

@dosu
But if I use integer timestamps I would get :
{"code":"invalid_param","message":"maximum recursion depth exceeded;\nmaximum recursion depth exceeded","status":400}

@Angelenx commented on GitHub (Oct 23, 2025): @dosu But if I use integer timestamps I would get : {"code":"invalid_param","message":"maximum recursion depth exceeded;\nmaximum recursion depth exceeded","status":400}
yindo commented 2026-02-21 20:04:42 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Oct 23, 2025):

The "maximum recursion depth exceeded" error when using integer timestamps for time-type metadata filtering in Dify 1.9.2 points to a backend bug—likely an infinite loop or unhandled recursive call in the metadata filtering logic. This isn't a validation or input format issue on your side, but a problem in how the backend processes certain valid numeric inputs for time-type fields.

Recent changes to metadata filtering introduced stricter type checks and new logic, which may have accidentally triggered this bug. There’s no workaround documented yet, but you can help diagnose by checking if the recursion happens with all time-type fields or only specific ones, and by confirming your metadata is stored as numeric timestamps in the database. This issue will likely require a code fix in the backend’s metadata filtering implementation.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Oct 23, 2025): <!-- Answer --> The "maximum recursion depth exceeded" error when using integer timestamps for time-type metadata filtering in Dify 1.9.2 points to a backend bug—likely an infinite loop or unhandled recursive call in the metadata filtering logic. This isn't a validation or input format issue on your side, but a problem in how the backend processes certain valid numeric inputs for time-type fields. Recent changes to metadata filtering introduced stricter type checks and new logic, which may have accidentally triggered this bug. There’s no workaround documented yet, but you can help diagnose by checking if the recursion happens with all time-type fields or only specific ones, and by confirming your metadata is stored as numeric timestamps in the database. This issue will likely require a code fix in the backend’s metadata filtering implementation. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/896cfba4-ae0d-42d5-8141-d1e32165e63b?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/896cfba4-ae0d-42d5-8141-d1e32165e63b?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/896cfba4-ae0d-42d5-8141-d1e32165e63b?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/896cfba4-ae0d-42d5-8141-d1e32165e63b?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/896cfba4-ae0d-42d5-8141-d1e32165e63b?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/896cfba4-ae0d-42d5-8141-d1e32165e63b?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/896cfba4-ae0d-42d5-8141-d1e32165e63b?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/27358)
yindo commented 2026-02-21 20:04:42 -05:00
Author
Owner
Copy Link
Copy Source

@Angelenx commented on GitHub (Oct 23, 2025):

@dosu

curl --request POST \
  --url http://127.0.0.1/v1/datasets/a67167dc-d89a-4c15-b8ea-c37150f6d4fe/retrieve \
  --header 'Authorization: Bearer dataset-un1vGoBCUPDv0SDGhetrrsF' \
  --header 'Content-Type: application/json' \
  --data '{
  "query": "GPU",
  "retrieval_model": {
    "search_method": "hybrid_search",
    "reranking_enable": false,
    "reranking_mode": null,
    "top_k": 15,
    "score_threshold_enabled": true,
    "score_threshold": 0.08,
    "weights": 0.7,
    "metadata_filtering_conditions": {
      "logical_operator": "and",
      "conditions": [
        {
          "name": "website_date",
          "comparison_operator": "after",
          "value": 1753401570
        },
        {
          "name": "website_date",
          "comparison_operator": "before",
          "value": 1761307200
        }
      ]
    }
  }
}'

return {"code":"invalid_param","message":"Error parsing message;\nError parsing message","status":400}

curl --request POST \
  --url http://127.0.0.1/v1/datasets/a67167dc-d89a-4c15-b8ea-c37dfg12d4fe/retrieve \
  --header 'Authorization: Bearer dataset-un1vGoBSFGDSgHL5HHvZopF' \
  --header 'Content-Type: application/json' \
  --data '{
  "query": "GPU",
  "retrieval_model": {
    "search_method": "hybrid_search",
    "reranking_enable": false,
    "reranking_mode": null,
    "top_k": 15,
    "score_threshold_enabled": true,
    "score_threshold": 0.08,
    "weights": 0.7,
    "metadata_filtering_conditions": {
      "logical_operator": "and",
      "conditions": [
        {
          "name": "website_date",
          "comparison_operator": "after",
          "value": 1761000000
        },
        {
          "name": "website_date",
          "comparison_operator": "before",
          "value": 1761307200
        }
      ]
    }
  }
}'

success

@Angelenx commented on GitHub (Oct 23, 2025): @dosu ```bash curl --request POST \ --url http://127.0.0.1/v1/datasets/a67167dc-d89a-4c15-b8ea-c37150f6d4fe/retrieve \ --header 'Authorization: Bearer dataset-un1vGoBCUPDv0SDGhetrrsF' \ --header 'Content-Type: application/json' \ --data '{ "query": "GPU", "retrieval_model": { "search_method": "hybrid_search", "reranking_enable": false, "reranking_mode": null, "top_k": 15, "score_threshold_enabled": true, "score_threshold": 0.08, "weights": 0.7, "metadata_filtering_conditions": { "logical_operator": "and", "conditions": [ { "name": "website_date", "comparison_operator": "after", "value": 1753401570 }, { "name": "website_date", "comparison_operator": "before", "value": 1761307200 } ] } } }' ``` return {"code":"invalid_param","message":"Error parsing message;\nError parsing message","status":400} ```bash curl --request POST \ --url http://127.0.0.1/v1/datasets/a67167dc-d89a-4c15-b8ea-c37dfg12d4fe/retrieve \ --header 'Authorization: Bearer dataset-un1vGoBSFGDSgHL5HHvZopF' \ --header 'Content-Type: application/json' \ --data '{ "query": "GPU", "retrieval_model": { "search_method": "hybrid_search", "reranking_enable": false, "reranking_mode": null, "top_k": 15, "score_threshold_enabled": true, "score_threshold": 0.08, "weights": 0.7, "metadata_filtering_conditions": { "logical_operator": "and", "conditions": [ { "name": "website_date", "comparison_operator": "after", "value": 1761000000 }, { "name": "website_date", "comparison_operator": "before", "value": 1761307200 } ] } } }' ``` success
yindo commented 2026-02-21 20:04:42 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Oct 23, 2025):

The 400 error ("Error parsing message") for one dataset and not the other is likely caused by differences in the metadata contents of the datasets. If any document in the failing dataset has a missing, malformed, or non-integer website_date value, the backend's filtering logic will fail when it tries to cast that field to a float for comparison. This is a known issue with Dify's stricter type validation in 1.9.2—filtering expects all relevant metadata fields to be valid numeric timestamps in every document included in the filter range.

To avoid this error, check that all documents in your dataset have website_date set as a valid integer timestamp. If some documents are missing this field or have it as a string or another type, update or clean your dataset so the metadata is consistent. The successful request likely worked because the filter range only included documents with valid timestamp values, while the failing request's wider range hit problematic metadata.

If you need to support documents with missing or non-numeric metadata, consider updating your ingestion process or cleaning your dataset before running these queries. This will help ensure consistent results and avoid backend parsing errors.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Oct 23, 2025): <!-- Answer --> The 400 error ("Error parsing message") for one dataset and not the other is likely caused by differences in the metadata contents of the datasets. If any document in the failing dataset has a missing, malformed, or non-integer `website_date` value, the backend's filtering logic will fail when it tries to cast that field to a float for comparison. This is a known issue with Dify's stricter type validation in 1.9.2—filtering expects all relevant metadata fields to be valid numeric timestamps in every document included in the filter range. To avoid this error, check that all documents in your dataset have `website_date` set as a valid integer timestamp. If some documents are missing this field or have it as a string or another type, update or clean your dataset so the metadata is consistent. The successful request likely worked because the filter range only included documents with valid timestamp values, while the failing request's wider range hit problematic metadata. If you need to support documents with missing or non-numeric metadata, consider updating your ingestion process or cleaning your dataset before running these queries. This will help ensure consistent results and avoid backend parsing errors. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/673d7ed8-33d0-4b08-ba1a-35d5f060622a?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/673d7ed8-33d0-4b08-ba1a-35d5f060622a?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/673d7ed8-33d0-4b08-ba1a-35d5f060622a?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/673d7ed8-33d0-4b08-ba1a-35d5f060622a?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/673d7ed8-33d0-4b08-ba1a-35d5f060622a?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/673d7ed8-33d0-4b08-ba1a-35d5f060622a?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/673d7ed8-33d0-4b08-ba1a-35d5f060622a?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/27358)
yindo commented 2026-02-21 20:04:42 -05:00
Author
Owner
Copy Link
Copy Source

@Angelenx commented on GitHub (Oct 24, 2025):

My documents metadata is created by script. It would check the type of the metadata, which make sure the type of website_date is integer timestamp.@dosu

@Angelenx commented on GitHub (Oct 24, 2025): My documents metadata is created by script. It would check the type of the metadata, which make sure the type of website_date is integer timestamp.@dosu
yindo commented 2026-02-21 20:04:42 -05:00
Author
Owner
Copy Link
Copy Source

@Angelenx commented on GitHub (Nov 10, 2025):

It is strange that when I try to modify the value of website_date, sometimes it reports an error of Error parsing message; Error parsing message, and sometimes it reports an error of maximum recursion depth exceeded; maximum recursion depth exceeded. Moreover, this issue also occurs when I switch from using the time type to using the number type! @dosu And in v1.9.1, It works normally, no error.

@Angelenx commented on GitHub (Nov 10, 2025): It is strange that when I try to modify the value of website_date, sometimes it reports an error of Error parsing message; Error parsing message, and sometimes it reports an error of maximum recursion depth exceeded; maximum recursion depth exceeded. Moreover, this issue also occurs when I switch from using the time type to using the number type! @dosu And in v1.9.1, It works normally, no error.
yindo commented 2026-02-21 20:04:42 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Nov 10, 2025):

This inconsistent error behavior is due to how Dify's backend processes metadata filtering for fields like website_date. When you use a string value (like "1970-01-01") for a filter that expects a number, the backend tries to cast it to a float and fails, resulting in a parsing error ("Error parsing message")—this matches the SQL error you saw. When you use integer timestamps but still get "maximum recursion depth exceeded", that's a sign of a bug in the backend's recursive filter logic, likely triggered by certain edge cases in your data or filter structure.

Both errors can also happen if some documents in your dataset have missing, null, or malformed website_date metadata—even if your script enforces types, legacy or partial data could still cause issues. The backend code does not robustly handle these cases, so the error you get depends on the specific data and filter combination at query time. Switching between time and number types doesn't fully resolve this because the backend expects consistent numeric types for numeric comparisons, and any inconsistency or unexpected structure can trigger either a parsing or recursion error depending on the code path taken (see code analysis).

To reduce these errors, ensure all documents have non-null, integer timestamp values for website_date and that your filter conditions are a flat list (not nested or cyclic). If you still see recursion errors, it's likely a backend bug that needs a code fix.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Nov 10, 2025): <!-- Answer --> This inconsistent error behavior is due to how Dify's backend processes metadata filtering for fields like `website_date`. When you use a string value (like `"1970-01-01"`) for a filter that expects a number, the backend tries to cast it to a float and fails, resulting in a parsing error ("Error parsing message")—this matches the SQL error you saw. When you use integer timestamps but still get "maximum recursion depth exceeded", that's a sign of a bug in the backend's recursive filter logic, likely triggered by certain edge cases in your data or filter structure. Both errors can also happen if some documents in your dataset have missing, null, or malformed `website_date` metadata—even if your script enforces types, legacy or partial data could still cause issues. The backend code does not robustly handle these cases, so the error you get depends on the specific data and filter combination at query time. Switching between time and number types doesn't fully resolve this because the backend expects consistent numeric types for numeric comparisons, and any inconsistency or unexpected structure can trigger either a parsing or recursion error depending on the code path taken ([see code analysis](https://github.com/langgenius/dify/blob/9dcb780fcba5c6cca3bdcb2912a999471fb92827/api/core/rag/retrieval/dataset_retrieval.py#L862-L1080)). To reduce these errors, ensure all documents have non-null, integer timestamp values for `website_date` and that your filter conditions are a flat list (not nested or cyclic). If you still see recursion errors, it's likely a backend bug that needs a code fix. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/38b6dbf9-a4f3-48fd-adfc-ee395798c39c?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/38b6dbf9-a4f3-48fd-adfc-ee395798c39c?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/38b6dbf9-a4f3-48fd-adfc-ee395798c39c?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/38b6dbf9-a4f3-48fd-adfc-ee395798c39c?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/38b6dbf9-a4f3-48fd-adfc-ee395798c39c?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/38b6dbf9-a4f3-48fd-adfc-ee395798c39c?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/38b6dbf9-a4f3-48fd-adfc-ee395798c39c?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/27358)
yindo commented 2026-02-21 20:04:42 -05:00
Author
Owner
Copy Link
Copy Source

@zhengshiqiang47 commented on GitHub (Dec 10, 2025):

I am using version 1.10.1 and encountering the same issue. When filtering metadata with numbers using the ≥ operator, I get the following error: 'maximum recursion depth exceeded; maximum recursion depth exceeded'.

@zhengshiqiang47 commented on GitHub (Dec 10, 2025): I am using version 1.10.1 and encountering the same issue. When filtering metadata with numbers using the ≥ operator, I get the following error: 'maximum recursion depth exceeded; maximum recursion depth exceeded'.
yindo commented 2026-02-21 20:04:42 -05:00
Author
Owner
Copy Link
Copy Source

@Angelenx commented on GitHub (Dec 15, 2025):

I am using version 1.10.1 and encountering the same issue. When filtering metadata with numbers using the ≥ operator, I get the following error: 'maximum recursion depth exceeded; maximum recursion depth exceeded'.

It may happen when using number type, too.

@Angelenx commented on GitHub (Dec 15, 2025): > I am using version 1.10.1 and encountering the same issue. When filtering metadata with numbers using the ≥ operator, I get the following error: 'maximum recursion depth exceeded; maximum recursion depth exceeded'. It may happen when using number type, too.
yindo commented 2026-02-21 20:04:43 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 21, 2026):

Hi, @Angelenx. I'm Dosu, and I'm helping the Dify team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported errors (400 or recursion depth exceeded) after updating from v1.9.1 to v1.9.2 when filtering metadata by time-type fields using integer timestamps.
  • The backend now requires numeric timestamps instead of date strings, but inconsistent or malformed metadata can cause parsing or recursion errors.
  • You confirmed metadata is stored as integer timestamps but still face inconsistent errors.
  • Another user on v1.10.1 also experiences the recursion error with numeric filters.
  • The problem seems linked to stricter validation and a backend bug introduced in recent versions.

Next Steps:

  • Please let me know if this issue is still relevant with the latest version of Dify by commenting here to keep the discussion open.
  • Otherwise, this issue will be automatically closed in 15 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Jan 21, 2026): Hi, @Angelenx. I'm [Dosu](https://dosu.dev), and I'm helping the Dify team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported errors (400 or recursion depth exceeded) after updating from v1.9.1 to v1.9.2 when filtering metadata by time-type fields using integer timestamps. - The backend now requires numeric timestamps instead of date strings, but inconsistent or malformed metadata can cause parsing or recursion errors. - You confirmed metadata is stored as integer timestamps but still face inconsistent errors. - Another user on v1.10.1 also experiences the recursion error with numeric filters. - The problem seems linked to stricter validation and a backend bug introduced in recent versions. **Next Steps:** - Please let me know if this issue is still relevant with the latest version of Dify by commenting here to keep the discussion open. - Otherwise, this issue will be automatically closed in 15 days. Thank you for your understanding and contribution!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#19871
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?