You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If applicable, what version of Node.js are you using?
18.17.0
Amplify CLI Version
12.10.0
What operating system are you using?
Mac
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No manual changes made
Describe the bug
When using the $util.transform.toElasticsearchQueryDSL function in a resolver for an @searchable directive, the resulting query incorrectly uses the match query type on .keyword fields when eq is specified in the filter. This behavior is inconsistent with expected functionality since .keyword fields are designed for exact matches and should use the term query type.
The issue causes tokenization of the input (e.g., 1:1 into ["1", "1"]), leading to failed matches in scenarios where exact matching is required.
Expected behavior
For fields indexed with the .keyword suffix and queried with eq, the $util.transform.toElasticsearchQueryDSL function should generate a term query instead of a match query. For example:
Expected Query:
{
"term": {
"aspectRatio.keyword": "1:1"
}
}
Actual Query:
{
"match": {
"aspectRatio.keyword": "1:1"
}
}
Reproduction steps
The issue can be reproduced in the following steps:
Define a GraphQL schema with an @searchable directive:
type GeneratedImage @model @searchable {
id: ID!
aspectRatio: String
}
Deploy the schema with Amplify CLI.
Add data to the OpenSearch index with an aspectRatio field containing values like "1:1".
This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.
How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
18.17.0
Amplify CLI Version
12.10.0
What operating system are you using?
Mac
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No manual changes made
Describe the bug
When using the $util.transform.toElasticsearchQueryDSL function in a resolver for an @searchable directive, the resulting query incorrectly uses the match query type on .keyword fields when eq is specified in the filter. This behavior is inconsistent with expected functionality since .keyword fields are designed for exact matches and should use the term query type.
The issue causes tokenization of the input (e.g., 1:1 into ["1", "1"]), leading to failed matches in scenarios where exact matching is required.
Expected behavior
For fields indexed with the .keyword suffix and queried with eq, the $util.transform.toElasticsearchQueryDSL function should generate a term query instead of a match query. For example:
Expected Query:
Actual Query:
Reproduction steps
The issue can be reproduced in the following steps:
Define a GraphQL schema with an @searchable directive:
Deploy the schema with Amplify CLI.
Add data to the OpenSearch index with an aspectRatio field containing values like "1:1".
Query using the following filter:
Observe that results are not returned for aspectRatio: "1:1".
Test $util.transform.toElasticsearchQueryDSL directly in a custom resolver:
Observe that the function returns a match query targeting .keyword instead of the expected term query:
Project Identifier
No response
Log output
Log snippet of the generated query DSL from $util.transform.toElasticsearchQueryDSL:
Expected query DSL:
Additional information
OpenSearch index mapping for the aspectRatio field confirms it is a text field with a .keyword subfield:
Executing a term query directly in OpenSearch works as expected:
Before submitting, please confirm:
The text was updated successfully, but these errors were encountered: