Incorrect resolver execution for operation type if given multiple types of operations

[cshadek]

I've noticed in both GraphiQL and BananaCakePop that if include both a named subscription and named mutation operation, that the mutation always fails when it is run. I'm interested if anyone else has this issue. When I remove the subscription, the mutation works fine.

subscription NewMessage {
  newMessage {
    ...message
  }
}

mutation CreateMessage {
  createMessage(input: {chatId: "aaa", text: "Hello there!"}) {
    message {
       ...message
    }
  }

If I try to run CreateMessage it fails. If I remove the subscription, it succeeds. In both cases, the subscription runs fine.

The error I get is a 500 code error. "{\"error\":true,\"reason\":\"The operation couldn’t be completed. (Pioneer.Pioneer<MyApp.MainAPI, MyApp.UserContext>.ResolveError error 0.)\"}"

I haven't add this problem with other servers, so I suspect this is a Pioneer specific bug with how Pioneer decodes the operations.

[cshadek]

Feel free to rename this issue. I wasn't too creative 😂

[d-exclaimation]

I was aware of that, it's an issue with decoding websocket message.

[d-exclaimation]

v0.7.2 should fix this, if not reopen the issue to let me know. I am pretty sure the incorrect operationType was the one that cause a subscription to be executed like a mutation and mutation executed like subscription