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

Settings some queries/mutations/subscriptions to null in @model directive results in more GraphQL statements/types being cut out than were set to null #765

Open
2 tasks done
SalmonMode opened this issue Nov 22, 2023 · 4 comments
Labels
bug Something isn't working

Comments

@SalmonMode
Copy link

How did you install the Amplify CLI?

npm

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

v16.20.2

Amplify CLI Version

12.8.2

What operating system are you using?

Ubuntu

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 @model directive in the GraphQL schema file to set queries/mutations/subscriptions to null (or specific subsets within them), things that were not set to null are still not generated. I've noticed that since my codegen is configured to go 2 levels deep, if a type that's fully nulled out in all these fields is included in the model of another that isn't, they will be generated.

For example:

type Resume
  @model(queries: null, mutations: null, subscriptions: null)
  @auth(
    rules: [
      { allow: owner, operations: [read] }
      { allow: private, provider: iam }
    ]
  ) {
  id: ID!
  owner: String
  text: String
  candidate: Candidate @belongsTo
  status: ResumeStatus!
}

type Candidate
  @model
  @auth(
    rules: [
      { allow: owner, operations: [read] }
      { allow: private, provider: iam }
    ]
  ) {
  id: ID!
  owner: String
  name: String
  email: AWSEmail
  phoneNumber: AWSPhone
  resumes: [Resume] @hasMany
}

This would result in the type for Resume to still be generated, as Candidate should be fully generated.

In this example, though:

type Application
  @model(queries: { list: null }, mutations: null, subscriptions: null)
  @auth(
    rules: [
      { allow: owner, operations: [read] }
      { allow: private, provider: iam }
    ]
  ) {
  id: ID!
  owner: String
  text: String
}

The get query for the model would not be generated, and the type for the Application itself might also not be generated (not entirely sure what's causing it to be generated or not generated).

Sometimes, even if a thing is not specified, it could be not generated at all. For example, I could not specify subscriptions or mutations, and only set queries to be null, and it would still not generate the subscriptions or mutations.

Expected behavior

The types would all still be generated (as they are useful in other contexts), and only the statements/types/resolvers that were set to null would not be created. Similarly, if queries is set to {list: null}, the get statement would still be generated. I'm also unclear if this means the associated resolvers are also not generated.

Reproduction steps

  1. Create a schema with a model that has a @model directive of @model(queries: { list: null }, mutations: null, subscriptions: null)
  2. Create another model with a similar directive, but include it as a relationship with another model that has an empty @model
    directive.
  3. Make sure the codegen is configured to go 2 nested levels deep
  4. Run amplify api push --y

Project Identifier

No response

Log output

# Put your logs below this line


Additional information

No response

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.
@SalmonMode SalmonMode added the pending-triage Issues that need further discussion to determine label Nov 22, 2023
@ykethan
Copy link

ykethan commented Nov 23, 2023

Hey, 👋 thanks for raising this! I'm going to transfer this over to our codegen repository for better assistance 🙂.

@ykethan ykethan transferred this issue from aws-amplify/amplify-cli Nov 23, 2023
@SalmonMode
Copy link
Author

SalmonMode commented Nov 28, 2023

Just an update, but I found a workaround, which entails explicitly stating every name for all operations/resolvers that I still want to keep. It looks a bit like this:

type Candidate
  @model(
    queries: { list: null, get: "getCandidate" }
    mutations: { create: null, update: "updateCandidate", delete: null }
    subscriptions: {
      onCreate: null
      onUpdate: ["onUpdateCandidate"]
      delete: null
    }
  )
  @auth(
    rules: [
      { allow: owner, operations: [read] }
      { allow: private, provider: iam }
    ]
  ) {
  id: ID!
  owner: String
  name: String
  email: AWSEmail
  phoneNumber: AWSPhone
  links: [String]
  knownCriteria: [CandidateCriterion]!
  resumes: [Resume] @hasMany
  jobApplications: [JobApplication] @hasMany
  assignments: [Assignment] @hasMany
}

@phani-srikar phani-srikar added bug Something isn't working and removed pending-triage Issues that need further discussion to determine labels Dec 11, 2023
@phani-srikar
Copy link
Contributor

I could not specify subscriptions or mutations, and only set queries to be null, and it would still not generate the subscriptions or mutations.

I wasn't able to reproduce this part and observed that if you have @model(queries: { list: null }), the get query is not being generated (the bug) and the mutations, subscriptions are generated as expected.

@juri-diener
Copy link

Any updates on this? I have kinda the same problem. I set this: @model(subscriptions: null, mutations: { create: null })
And now any mutation is not generated. I use the latest amplify version. Just did today an update of amplify and the v6. Now it does not work anymore????

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants