Open jbschooley opened 2 years ago
I'm having the same problem.
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
What are the next steps on this issue? I don't want to expose default query to the client!
Before opening, please confirm:
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 eitheror
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 withThus, 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
GraphQL schema(s)
Project Identifier
No response
Log output
Additional information
No response