GraphQL Transformer v1 to v2 migration - @searchable with auth rule for groupsField is not returning results from OpenSearch

[malcomm]

Before opening, please confirm:

• I have searched for duplicate or closed issues and discussions.
• I have read the guide for submitting bug reports.
• I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

JavaScript Framework

Angular

Amplify APIs

GraphQL API

Amplify Version

v5

Amplify Categories

api

Backend

Amplify CLI

Environment information

  System:
    OS: macOS 15.1.1
    CPU: (12) arm64 Apple M2 Max
    Memory: 25.10 GB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.13.0 - /usr/local/bin/node
    Yarn: 1.22.22 - /opt/homebrew/bin/yarn
    npm: 9.7.2 - /opt/homebrew/bin/npm
  Browsers:
    Safari: 18.1.1
  npmPackages:
    @angular-devkit/build-angular: ^17.3.6 => 17.3.6 
    @angular/animations: ^17.3.7 => 17.3.7 
    @angular/cdk: ^17.3.7 => 17.3.7 
    @angular/cli: ^17.3.6 => 17.3.6 
    @angular/common: ^17.3.7 => 17.3.7 
    @angular/compiler: ^17.3.7 => 17.3.7 (9.0.0)
    @angular/compiler-cli: ^17.3.7 => 17.3.7 
    @angular/compiler/testing:  undefined ()
    @angular/core: ^17.3.7 => 17.3.7 (9.0.0)
    @angular/core/testing:  undefined ()
    @angular/forms: ^17.3.7 => 17.3.7 
    @angular/language-service: ^17.3.7 => 17.3.7 
    @angular/platform-browser: ^17.3.7 => 17.3.7 
    @angular/platform-browser-dynamic: ^17.3.7 => 17.3.7 
    @angular/router: ^17.3.7 => 17.3.7 
    @fortawesome/fontawesome-free: ^5.15.4 => 5.15.4 
    @saithodev/ts-appversion: ^1.3.1 => 1.3.1 
    @types/file-saver: ^2.0.5 => 2.0.5 
    @types/jasmine: ~5.1.4 => 5.1.4 
    @types/jasminewd2: ~2.0.10 => 2.0.10 
    @types/node: ^20.11.24 => 20.11.24 
    aws-amplify: ^5.3.24 => 5.3.24 
    bootstrap: ^4.6.2 => 4.6.2 
    codelyzer: ^6.0.2 => 6.0.2 
    core-js: ^2.5.4 => 2.6.5 
    enum-values: ^1.2.1 => 1.2.1 
    file-saver: ^2.0.5 => 2.0.5 
    jasmine-core: ~5.1.2 => 5.1.2 (2.8.0, 4.6.0)
    jasmine-spec-reporter: ~5.0.0 => 5.0.2 
    jquery: ^3.5.1 => 3.5.1 
    karma: ~6.4.3 => 6.4.3 
    karma-chrome-launcher: ~3.2.0 => 3.2.0 
    karma-coverage: ~2.2.0 => 2.2.1 
    karma-coverage-coffee-example:  1.0.0 
    karma-jasmine: ~5.1.0 => 5.1.0 
    karma-jasmine-html-reporter: ~2.1.0 => 2.1.0 
    moment: ^2.29.4 => 2.29.4 
    ngx-autosize: ^2.0.4 => 2.0.4 
    ngx-bootstrap: ^12.0.0 => 12.0.0 
    ngx-filesaver: ^14.0.0 => 14.0.0 
    ngx-papaparse: ^7.0.0 => 7.0.0 
    ngx-toastr: ^18.0.0 => 18.0.0 
    node-example:  1.0.0 
    popper.js: ^1.16.1 => 1.16.1 
    primeicons: ^6.0.1 => 6.0.1 
    primeng: ^17.10.0 => 17.10.0 
    protractor-example:  1.0.0 
    rxjs: ~7.8.1 => 7.8.1 (6.6.7)
    rxjs/ajax:  undefined ()
    rxjs/fetch:  undefined ()
    rxjs/internal-compatibility:  undefined ()
    rxjs/operators:  undefined ()
    rxjs/testing:  undefined ()
    rxjs/webSocket:  undefined ()
    sample-app:  1.0.0 
    ts-node: ~8.3.0 => 8.3.0 
    tslib: ^2.3.0 => 2.6.2 (1.14.1, 2.7.0, 1.13.0)
    tslint: ~6.1.3 => 6.1.3 
    typescript: ~5.3.3 => 5.3.3 
    typescript-example:  1.0.0 
    zone.js: ~0.14.4 => 0.14.4 (0.10.3)
  npmGlobalPackages:
    @angular/cli: 17.3.7
    @aws-amplify/cli: 11.1.0
    create-react-app: 5.0.1
    graphile-migrate: 2.0.0-rc.2
    json-diff: 1.0.6
    npm: 9.7.2
    yarn: 1.22.22

Describe the bug

I'm in the middle of a GraphQL Transformer v1 to v2 migration and so far things are working pretty well. I ran into an issue with OpenSearch where a user that has access to a model via groupsField:

type ResearchSubject
  @model
  @auth(rules: [
    { allow: groups, groups: ["admin"] },
    { allow: groups, groupsField: "groupsCanAccess" }
  ])
  @searchable
{

Is not able to return any results using a search function: searchResearchSubjects. This works just fine for admins and this worked under v1.

When reading the documentation for the upgrade I don't believe it mentions this is no longer supported, but maybe I missed something?

Note: the user is able to return records from list and get which hit DynamoDB.

Expected behavior

A user that has access to records via groupsField should return records correctly from OpenSearch.

Reproduction steps

1. Schema with @searchable and @auth rule with groupsField
2. OpenSearch queries should return correctly

Code Snippet

this.apiService.SearchResearchSubjects()

Log output

No errors

aws-exports.js

No response

Manual configuration

No response

Additional configuration

No response

Mobile Device

No response

Mobile Operating System

No response

Mobile Browser

No response

Mobile Browser Version

No response

Additional information and screenshots

No response

[chrisbonifacio]

Hi @malcomm 👋 thanks for raising this issue. Can you share the network request, payload, and response from AppSync?

I'm curious to see what the headers are and what the response looks like. are you getting an empty array vs null, or are you getting some data but not relational, etc.

It's also worth noting that there are some breaking changes for OpenSearch instances when migrating from graphql transformer v1 to v2. You have to reindex the data in OpenSearch again.

From the docs:

https://docs.amplify.aws/gen1/react/tools/cli/migration/transformer-migration/?t#changes-that-amplify-cli-requires-you-to-manually-migrate

I have used @searchable in my GraphQL schema. When migrating to the new GraphQL Transformer, the OpenSearch domain will be replaced with OpenSearch version 7.10 which may result in data loss due to the breaking changes (https://docs.aws.amazon.com/opensearch-service/latest/developerguide/version-migration.html) in OpenSearch from version 6.x.x.
To preserve the OpenSearch domain data, manually take a snapshot of the opensearch domain, migrate to v2 transformer and restore the snapshot as described here.
I use auto generated searchable queries
Clients using OpenSearch version >= 1.1 will need to modify their searchable resolvers using the resolver override. Clients using version >= 1.1 will need to change the indexPath of the query from name/doc/_search to name/_search. Without this, all autogenerated searchable queries will fail. You can easily do this by copying the built templates and moving them to a resolver folder on the same level as the build folder.

[malcomm]

@chrisbonifacio - thanks for the response. Please see log output from AppSync:
ad81162c-5fda-48c5-af70-69ba2bbc0f74_log.txt.

Response is empty array:

{
  "data": {
    "searchResearchSubjects": {
      "items": []
    }
  }
}

Also of note, when I am logged in with the same user and I run the listResearchSubjects, I am getting results:

{
  "data": {
    "listResearchSubjects": {
      "items": [
        {
          "id": "d7bd9dca-8184-4264-84aa-9353eb05733d",
          "groupsCanAccess": [
            "Group2"
          ]
        },
...

I am including the logs for a different user, which has the role of admin:
20663968-1ae3-4a86-b7d4-6ad50487d84d_admin_user_log.txt. When I run the same query with this user I am getting results:

{
  "data": {
    "searchResearchSubjects": {
      "items": [
        {
          "id": "ff80b193-f432-4221-92c2-70322ca7bfac",
          "groupsCanAccess": [
            "Group1"
          ]
        },
...

And just to be sure: during the v1 to v2 upgrade process I initially removed the @searchable and added that back to create the OpenSearch brand new. I then used the Backfill OpenSearch index from DynamoDB table script (ddb_to_es.py) to repopulate all the data.

[chrisbonifacio]

It looks like from the log.txt file the Request headers had an Authorization header which I'm assuming was set to a cognito access token. can you also share the VTL template for the query you're trying to perform? you should be able to find it in the amplify/api/<apiName>/build/resolvers folder.

[malcomm]

@chrisbonifacio yes the project is using Cognito auth. Here are all the resolvers for that query:

Query.searchResearchSubjects.auth.1.req.vtl.txt
Query.searchResearchSubjects.postAuth.1.res.vtl.txt
Query.searchResearchSubjects.req.vtl.txt
Query.searchResearchSubjects.res.vtl.txt

Thank you

[malcomm]

@chrisbonifacio - any updates on this? Thank you

[chrisbonifacio]

Hi @malcomm I don't see anything obviously wrong with the way the VTL template was generated. Just out of curiosity, can you share how the groups are defined and spelled on the user's access token?

My best guess is there must be some discrepancy between the group on the record and the group on the Cognito access token.

It might also help to see what the auth VTL template looks like for the listResearchSubjects query to compare the logic.

[malcomm]

@chrisbonifacio - Here are the listResearchSubjects templates:

Query.listResearchSubjects.auth.1.req.vtl.txt
Query.listResearchSubjects.postAuth.1.req.vtl.txt
Query.listResearchSubjects.req.vtl.txt
Query.listResearchSubjects.res.vtl.txt

The groups from the auth token are exactly how they are in Cognito.

[malcomm]

@chrisbonifacio - any luck looking a those templates? Thank you -- marcus

[chrisbonifacio]

Thank you for sharing the other auth template. There are some differences in the way they check for group auth which might be causing some inconsistencies in the way the auth rule is implemented between them.

1. The search resolver uses Elasticsearch's terms_set query with a minimum_should_match_script set to "1", which requires at least one exact match in the groupsCanAccess field.

https://opensearch.org/docs/latest/query-dsl/term/terms-set/

might be related to this old issue regarding the auth resolver for searchable queries: aws-amplify/amplify-cli#5833

To try a potential wokraorund for this issue, can you try changing the seach resolver's logic to this and let me how it goes?

-#set( $group0 = {
- "terms_set": {
-      "groupsCanAccess": {
-          "terms": $groupClaim0,
-          "minimum_should_match_script": {
-              "source": "1"
-      }
-    }
-  }
+#set( $group0 = {
+  "terms": {
+    "groupsCanAccess": $groupClaim0
+  }
+})

This modification should make the search behavior more consistent with the list operation by using a simpler terms query instead of the more restrictive terms_set query.

You already confirmed but anyone else running into this issue should ensure that the group field on the schema contains the exact group names that match the Cognito group names, as the comparison is case-sensitive and must match exactly.

[chrisbonifacio]

I'm also going to transfer this issue over to the category-api repo for better support related to OpenSearch, behaviors related to autogenerated resolvers, and migration in general.

[malcomm]

@AnilMaktala - hello! Any ideas what's going on here? Development is blocked on this.

[AnilMaktala]

Hey @malcomm, Have you attempted the workaround suggested in the following link: #3060 (comment)? Additionally, if you are on Discord, kindly share your Discord username.

[malcomm]

@AnilMaktala - I just tried the workaround and either I'm not making the change correctly or the change is not working.

[Siqi-Shan]

Hey @malcomm, thanks for sharing resolver-related information and issue context. We'll investigate further and see what's going on with the generated resolvers. Will get to you once we have further discoveries. Thanks again for your patience and followup.

[AnilMaktala]

Hey @malcomm,Apologies for the delay. I was unable to reproduce the issue using the schema provided below. Please let me know your availability for a follow-up call.

type ResearchSubject
  @model
  @auth(
    rules: [
      { allow: groups, groups: ["admin"] }
      { allow: groups, groupsField: "groupsCanAccess" }
    ]
  )
  @searchable {
  id: ID
  minutes: Int!
  groupsCanAccess: [String]
}