0

Using the GRANDstack Starter template project, I'm using apollo-server in combination with neo4j. I have a CreateParticipant mutation (defined in the schema.graphql with a @cypher directive) that I want to reuse for a new mutation.

The simplified resolver that gets passed into the augmented schema looks like this:

const resolvers = {
  Mutation: {
    UploadCSV: async (parent, { file }, context, info) => {
      // some data processing using file omitted
      const payload = { name: 'Just a name' }
      const result = resolvers.Mutation.CreateParticipant(
        parent,
        payload,
        context,
        info
      )
      return 'thanks StackOverflow'
    },
  },
}

The mutations are defined in the schema.graphql file like this:

CreateParticipant(name: String!, id: ID = null): Participant
@cypher(
  statement: """
  CREATE (par:Participant {
    name: $name,
    id: coalesce($id, apoc.create.uuid())
  })
  RETURN par
  """
)

UploadCSV(file: Upload!): String

When I try to upload a file now via the frontend, apollo-server throws an error when executing resolvers.Mutation.CreateParticipant(parent, payload, context, info). Payload is an object with key/value pairs that the mutation expects.

The thrown error is:

Error: Do not know how to handle this type of mutation. Mutation does not follow naming convention.

I'm wondering if passing the unmodified info is the reason this isn't working.

manonthemat
  • 6,101
  • 1
  • 24
  • 49
  • Have you tried narrowing down which of the functions within UploadCSV csv is throwing? this way you can rule out graphql configuration setup vs csv read, vs create participant mutation code? Also is there a reason you are not awaiting function csvToParticipant? This will help clean up this code and make it more readable. – Edward Romero Sep 04 '20 at 00:28
  • @EdwardRomero good points. I simplified the example. The function actually did what it was supposed to do. I simplified it with some hard-coded data. – manonthemat Sep 04 '20 at 15:22
  • It looks like the neo4j-graphql.js library is trying to handle the UploadCSV resolver instead of using your custom resolver. Try adding the `@neo4j_ignore` directive in the trypedefs to ensure it's not trying to run an auto-generated resolver `UploadCSV(file: Upload!): String @neo4j_ignore` – William Lyon Sep 07 '20 at 23:12
  • @WilliamLyon thank you for your suggestion. I tried this as well. Same error. – manonthemat Sep 07 '20 at 23:51

1 Answers1

0

Don’t try to call the mutation inside another. Instead pull the create participant logic out and import the functions that are generic. This allows you to keep a separation of concerns between the upload csv and the create participants mutations.

Some good resources:

Nested Graphql Resolvers

Reusing Resolvers Conversation

Edward Romero
  • 2,905
  • 1
  • 5
  • 17
  • The CreateParticipant mutation itself is the minimal viable function. It is implemented in the schema via cypher directive. It would make sense in this scenario to reuse said mutation in the UploadCSV mutation, because all I'm doing here is transforming the uploaded data so it can be used in prior written mutation (that's stil being used elsewhere). – manonthemat Sep 04 '20 at 16:21
  • @manonthemat gotcha, can you provide the Create participant schema definition so that we can have the whole picture – Edward Romero Sep 04 '20 at 16:53
  • added the CreateParticipant mutation. I'm wondering if my `info` is wrong for CreateParticipant. – manonthemat Sep 04 '20 at 17:03
  • @manonthemat so it seems reusing resolves is uncommon https://spectrum.chat/apollo/apollo-server/reusing-resolvers-vs-delegatetoschema~22cb3b1f-c1e1-49aa-bddd-69ee09eac815?m=MTU1MDgzNzY2MTY3Mw== and people tend to go through the method I originally mentioned in response. But if you still want to do it, here might be a way https://spectrum.chat/apollo/apollo-server/reusing-resolvers-vs-delegatetoschema~22cb3b1f-c1e1-49aa-bddd-69ee09eac815?m=MTU1MDkyOTM4NzgzNw== – Edward Romero Sep 04 '20 at 19:52