When sending a subscription with fragments, the request is sent to the http endpoint instead of the ws endpoint

@ntziolis commented on Sat Aug 18 2018

Summary When using fragments + NOT naming the subscription Prisma (not app endpoint) returns { data: null } straight away + closes the connection (no spinner in playground).

To Reproduce Steps to reproduce the behavior:

1. Feel free to use my endpoint: https://eu1.prisma.sh/public-silvermole-100/subscription-fragment/dev or Create new service in prisma with the following schema:

type Post {
  id: ID! @unique
}

1. Execute the below in playground against prisma endpoint

fragment PostFragment on Post{
  id
}
subscription {post{node{  ...PostFragment  }}}

1. See error Returns { data: null } straight away + closes the connection (no spinner in playground)

Expected behavior Subscription not be closed (spinning wheel in playground). Data should be returned when there is an event the subscription matches.

Screenshots If applicable, add screenshots to help explain your problem.

Versions (please complete the following information):

• Prisma Server: 1.15-beta-1 (current dev servers)

Context When either giving the subscription a name or removing the fragments it works just fine (spinning wheel in playground):

fragment PostFragment on Post{
  id
}
subscription SomeName{post{node{  ...PostFragment  }}}

or

subscription {post{node{  id  }}}

---

@marktani commented on Fri Sep 28 2018

This seems to be a bug in the Playground. Instead of opening a websocket connection, the Playground seems to send a query, which returns the null data:

curl 'https://eu1.prisma.sh/public-silvermole-100/subscription-fragment/dev' -H 'origin: https://eu1.prisma.sh' -H 'accept-encoding: gzip, deflate, br' -H 'accept-language: en-US,en;q=0.9,de;q=0.8,es;q=0.7' -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36' -H 'content-type: application/json' -H 'accept: */*' -H 'referer: https://eu1.prisma.sh/public-silvermole-100/subscription-fragment/dev' -H 'authority: eu1.prisma.sh' --data-binary '{"operationName":null,"variables":{},"query":"fragment PostFragment on Post {\n  id\n}\n\nsubscription {\n  post {\n    node {\n      ...PostFragment\n    }\n  }\n}\n"}' --compressed

results in

{
  "data" : {
    "post" : null
  }
}

As you can see, the endpoint is https://eu1.prisma.sh/public-silvermole-100/subscription-fragment/dev and not wss://..., so what the server returns for this is undefined.

I’ll move this to the graphql-playground repository. As a workaround, use any other subscription client.

[Miragecoder]

I’m currently working on a project with Apollo - which also ships with the GraphQL Playground - and I ran into the same behaviour when using fragments on a subscription. With my situation, I can workaround this issue using inline fragments. Maybe that can help for a while!

[dunatron]

Upgrading the prisma-binding and naming the subscriptions on the client seems to fix the issue. e.g.

const MESSAGE_CREATED_SUBSCRIPTION = gql`
  subscription($where: MessageSubscriptionWhereInput) {
    messageSub(where: $where) {
      mutation
      node {
        ...Message
      }
    }
  }
  ${fragments.message}
`;

becomes

const MESSAGE_CREATED_SUBSCRIPTION = gql`
  subscription NEW_MESSAGE_SUB($where: MessageSubscriptionWhereInput) {
    messageSub(where: $where) {
      mutation
      node {
        ...Message
      }
    }
  }
  ${fragments.message}
`;