Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[AppSync] Inconsistent @searchable Query behavior for eq filter using $util.transform.toElasticsearchQueryDSL #14036

Closed
2 tasks done
Klm12 opened this issue Dec 8, 2024 · 1 comment
Labels
pending-triage Issue is pending triage

Comments

@Klm12
Copy link

Klm12 commented Dec 8, 2024

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:

{
  "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".

Query using the following filter:

query {
  searchGeneratedImages(filter: { aspectRatio: { eq: "1:1" } }) {
    items {
      id
      aspectRatio
    }
  }
}

Observe that results are not returned for aspectRatio: "1:1".

Test $util.transform.toElasticsearchQueryDSL directly in a custom resolver:

#set($dsl = $util.transform.toElasticsearchQueryDSL({
  "aspectRatio": { "eq": "1:1" }
}))
$util.toJson($dsl)

Observe that the function returns a match query targeting .keyword instead of the expected term query:

{
  "match": {
    "aspectRatio.keyword": "1:1"
  }
}

Project Identifier

No response

Log output

Log snippet of the generated query DSL from $util.transform.toElasticsearchQueryDSL:

{
  "match": {
    "aspectRatio.keyword": "1:1"
  }
}

Expected query DSL:

{
  "term": {
    "aspectRatio.keyword": "1:1"
  }
}

Additional information

OpenSearch index mapping for the aspectRatio field confirms it is a text field with a .keyword subfield:

"aspectRatio": {
  "type": "text",
  "fields": {
    "keyword": {
      "type": "keyword",
      "ignore_above": 256
    }
  }
}

Executing a term query directly in OpenSearch works as expected:

{
  "term": {
    "aspectRatio.keyword": "1:1"
  }
}

Before submitting, please confirm:

  • I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
  • I have removed any sensitive information from my code snippets and submission.
@Klm12 Klm12 added the pending-triage Issue is pending triage label Dec 8, 2024
@Klm12 Klm12 closed this as completed Dec 8, 2024
Copy link

github-actions bot commented Dec 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pending-triage Issue is pending triage
Projects
None yet
Development

No branches or pull requests

1 participant