Skip to content
This repository has been archived by the owner on Sep 3, 2021. It is now read-only.

[Bug] Auto-generated mutations cause error when first field on type is not Scalar type #191

Open
btroop opened this issue Feb 9, 2019 · 3 comments

Comments

@btroop
Copy link

btroop commented Feb 9, 2019

I think I found a bug where, in the type definitions, if the first field on a type is not a scalar the auto generated mutations fail to pass validation, resulting in the following error:

The type of Mutation.Update(<field>:) must be Input Type but got: <Type>!

 throw new Error(errors.map(function (error) {
Error: The type of Mutation.UpdateRentalAgreement(renter:) must be Input Type but got: Renter!.
The type of Mutation.DeleteRentalAgreement(renter:) must be Input Type but got: Renter!.
The type of _RentalAgreementInput.renter must be Input Type but got: Renter!.

here's the type def I was playing around with that caused the issue.

works:

type RentalAgreement {
  uuid: ID
  renter: Renter @relation(name:"RENTER", direction:"OUT")
  vehicle: Vehicle @relation(name:"VEHICLE_RENTED", direction: "OUT")
  rentedFrom: RentalLocation @relation(name:"RENTED_FROM", direction:"OUT")
  returnedTo: RentalLocation @relation(name:"RETURNED_TO", direction:"OUT")
  beginningMileage: Int
  endingMileage: Int
  startDate: String
  endDate: String
  status: String
  createdBy: Employee @relation(name:"CREATED", direction:"IN")
}

throws error:

type RentalAgreement {
  renter: Renter @relation(name:"RENTER", direction:"OUT")
  vehicle: Vehicle @relation(name:"VEHICLE_RENTED", direction: "OUT")
  rentedFrom: RentalLocation @relation(name:"RENTED_FROM", direction:"OUT")
  returnedTo: RentalLocation @relation(name:"RETURNED_TO", direction:"OUT")
  beginningMileage: Int
  endingMileage: Int
  startDate: String
  endDate: String
  status: String
  createdBy: Employee @relation(name:"CREATED", direction:"IN")
}

I kept deleting fields referring to other types and restarting the server until I got down to the "beginningMileage" field; the error promptly went away once the first field was the scalar type.

Neo4j 3.5, neo4jgraphql-js @ 2.3.1, makeAugmentedSchema({typeDefs})

@chadnorvell
Copy link

I've run into the same problem. It works fine if the first field is scalar, and breaks with the same type of error if the first field is a relation. There's no difference in the actual fields, just their order in the type definition.

@chadnorvell
Copy link

From very cursory testing, it looks like the first field defined on a type is used to define the auto-generated _*Input types. GraphQL input types can only have scalar fields, so it makes sense that the resulting schema would not validate.

@michaeldgraham
Copy link
Collaborator

#608

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants