Can't disable search query on a model type (transformer v2)

[jbschooley]

Before opening, please confirm:

• [X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
• [X] I have searched for duplicate or closed issues.
• [X] I have read the guide for submitting bug reports.
• [X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
• [X] I have removed any sensitive information from my code snippets and submission.

How did you install the Amplify CLI?

npm

If applicable, what version of Node.js are you using?

v16.15.0

Amplify CLI Version

9.2.1

What operating system are you using?

Windows

Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.

Added another API key

Amplify Categories

auth, storage, function, api

Amplify Commands

push

Describe the bug

When I try to disable the autogenerated search query resolver on a searchable model type using @searchable(queries: {search: null}), amplify push fails with either

Cannot read property 'addToSlot' of undefined

or

Cannot extend nonexistent type 'SearchableAggregateResult'.

I am not sure what makes the difference between which error it throws, as I get different errors when triggering this issue on two similar types.

Similarly, @searchable(queries: null) fails with

Cannot read property 'search' of null

Thus, there is no way to disable the search query. For some of these data types, I have custom pipelines that I would like to use instead of the autogenerated ones to perform search functions, and others are set up with search so that lambdas can perform searches but the raw search should not be accessible to the end user. Right now my only option is to set the query name to something obscure and hope the user never finds it, and/or override the resolver with a blank one so it errors out, but these are messy solutions.

This worked fine using the v1 transformer, and @model(queries: {get: null, ...}) and @model(queries: null) both work as intended, so I would expect that @searchable would work the same way.

Additionally, Cannot read property 'addToSlot' of undefined is a very non-descriptive error message and it took me hours to find the cause.

I am having this issue on both a large complicated backend that is being migrated from v1 and a small side project that was written from scratch using v2.

Expected behavior

@searchable(queries: {search: null}) and @searchable(queries: null) should both disable automatic generation of that model's search query while still creating an OpenSearch index and DynamoDB stream for the model.

Reproduction steps

1. Create a model
2. Add @searchable and disable the autogenerated query using one of the methods described above
3. Attempt to push it

GraphQL schema(s)

UserEngagement raw data should never be accessible to the end user, but must have @searchable as it is referenced by other custom search resolvers.

type UserEngagement @model(queries: null, mutations: null, subscriptions: null) @searchable(queries: {search: null) {
  id: ID!
  posts_seen: [String]
  posts_voted: [String]
}

throws the addToSlot error, while

type UserEngagement @model(queries: null, mutations: null, subscriptions: null) @searchable(queries: {search: "ZZZ_searchUserEngagements"}) {
  id: ID!
  posts_seen: [String]
  posts_voted: [String]
}

allows the push to complete

Project Identifier

No response

Log output

# Put your logs below this line

Additional information

No response

[thomasoehri]

I'm having the same problem.

[AnilMaktala]

Hi @jbschooley 👋, Apologies for the delay and thank you for raising this issue. We were able to recreate the issue using the schema mentioned below. As a result, we have classified it as a bug for the team to evaluate further.

type UserEngagement @model(queries: null, mutations: null, subscriptions: null) @searchable(queries:null) {
  id: ID!
  posts_seen: [String]
  posts_voted: [String]
}

genereated search query in queries. js file

[ccks01]

What are the next steps on this issue? I don't want to expose default query to the client!