Prisma1: subscription with fragments does not fire properly

[canercandan]

Following the resolver example here, if you call a subscription with a fragment as follow:

subscription {
  publications {
    mutation
    node {
      ...Fields
    }
  }
}

fragment Fields on Post {
  id
  title
}

It will returns a response right away with a null data such as the one below and does not listen for changes.

{
  "data": {
    "data": {
      "publications": null
    }
  }
}

Removing the fragment keeps the connection on and listening, and the mutations are triggered properly on changes.

Someone else can confirm?

$ prisma --version
prisma/1.3.3 (linux-x64) node-v8.7.0

Edit: One more thing, this issue does not occur when we use the prisma generated subscriptions with fragments (at the database level).

[Ranatchai]

+1 I have the same issue.

[divyenduz]

I am also able to replicate this issue.

[lowsky]

I also ran into this, same issue: when replacing the fragment with regular fields, all works fine, but after introducing a fragment into the client-side query, it

• creates one spurious websocket response containing just 'null'

returns a response right away with a null data

• does not fire up after a change should have triggered an event
• works, when regularly connecting the database prisma directly.
  In the logs I additionally find these lines:
  ```
  query: Promise {
  TypeError: Cannot read property 'variableDefinitions' of undefined
  at Object. (//node_modules/graphql-tools/dist/stitching/delegateToSchema.js:64:155)
  at step (//node_modules/graphql-tools/dist/stitching/delegateToSchema.js:40:23)
  at Object.next (//node_modules/graphql-tools/dist/stitching/delegateToSchema.js:21:53)
  at //node_modules/graphql-tools/dist/stitching/delegateToSchema.js:15:71
  at new Promise ()
  at __awaiter (//node_modules/graphql-tools/dist/stitching/delegateToSchema.js:11:12)
  at Object.delegateToSchema (//node_modules/graphql-tools/dist/stitching/delegateToSchema.js:49:12)
  at Proxy. (//node_modules/prisma-binding/dist/src/Handler.js:54:36)
  at formatValue (util.js:430:38)
  at formatProperty (util.js:831:11) },
  mutation: Promise {
  TypeError: Cannot read property 'variableDefinitions' of undefined
  at Object. (//node_modules/graphql-tools/dist/stitching/delegateToSchema.js:64:155)
  at step (//node_modules/graphql-tools/dist/stitching/delegateToSchema.js:40:23)
  at Object.next (//node_modules/graphql-tools/dist/stitching/delegateToSchema.js:21:53)
  at /node_modules/graphql-tools/dist/stitching/delegateToSchema.js:15:71
  at new Promise ()
  at __awaiter (//node_modules/graphql-tools/dist/stitching/delegateToSchema.js:11:12)
  at Object.delegateToSchema (//node_modules/graphql-tools/dist/stitching/delegateToSchema.js:49:12)
  at Proxy. (//node_modules/prisma-binding/dist/src/Handler.js:54:36)
  at formatValue (util.js:430:38)
  at formatProperty (util.js:831:11) },

and many or these: ```
(node:20312) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 24): TypeError: Cannot read property 'variableDefinitions' of undefined
(node:20312) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 26): TypeError: Cannot convert a Symbol value to a string

Hope this helps somehow?

[divyenduz]

I am able to replicate this with apollo-link-* and graphql-tools. Most likely a bug in graphql-tools, will work on isolating the issue further.

[bazaglia]

I'm getting the same error in query object. TypeError: Cannot read property 'variableDefinitions' of undefined.

I can only see this error when I console.log the prisma instance. Despite the error, prisma-binding is seems to be working fine.

[frankdugan3]

When using a query with subscribeToMore, this can really add a lot of duplication in the client code. Would be nice to see this get some attention.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[deiucanta]

@marktani I have this issue as well. @divyenduz provided a reproduction repo

[samdenty]

Found an issue with GraphQL Playground. It seems when a fragment is placed inside the query, instead of sending it over WebSocket, it sends it in a POST request

[ntziolis]

@marktani You closed #1810 stating that this issue provides a reproduction. Do you have everything you need to tacke this? Let me know if you still need a clean repro and I will set it up

The duplicate code issue is really getting out of hand in our codebase. It leads to a lot of the following situations:

• devs forgetting to update both fragment and subscription when adding / renaming fields => hours wasted until realizing their mistake
• devs forgetting or not knowing that the fragmenting subscription issue exists => hours wasted until they realize the framework is broken here

[divyenduz]

@ntziolis : I am not able to reproduce it anymore with my original reproduction (this bypasses graphql-yoga to reproduce) https://github.com/divyenduz/subscriptions-fragment-bug

Looks like updating an underlying a package fixed it.

If possible, can you please provide a clean reproduction?

[ntziolis]

@divyenduz

When using the current boilerplate for typescript advanced:
graphql create subscription-fragment --boilerplate typescript-advanced

What I found:

1. A subscription with a name AND a fragment executed against the graphql-yoga does NOT return null anymore
2. But instead it now returns the following error "TypeError : Cannot read property 'post' of undefined" AND the socket is still closed
3. However when executing the same subscription against the prisma endpoint it works as expected
4. Separate issue: When removing the name of the subscription it still returns null and closes the connection no matter if executing against graphql-yoga endpoint OR the prisma endpoint directly

Summarizing:
So while one issue seems to be resolved (graphql-yoga responding with null), using fragments with subscriptions end to end still doesn't work as we now get a different error from the graphql-yoga endpoint.

For 4 I have opened a separate issue here: https://github.com/prisma/prisma/issues/2942

You can check this quickly:
https://eu1.prisma.sh/public-silvermole-100/subscription-fragment/dev

The following breaks (returns null and closes connection):

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

While this works just fine:

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

[ntziolis]

So I found the cause for the newly seen type error:

• While [email protected] do solve the null return issue for subscriptions (with name) and fragments (2.1.3 still returns null for subscriptions with fragments)
• but at the same time 2.1.4 introduces the new type error (mentioned above) bug for ALL subscriptions. See issue https://github.com/prisma/prisma-binding/issues/229

Applying the fix mentioned in the issue thread for the type error (in my node modules folder) I can confirm that :

• subscription with fragments and NAME now work as expected
• still same issues for subscriptions with fragments and NO name #2942

Note:
The type error is actually part of the graphl-bindings not prisma-bindings itself

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[marktani]

Closed as duplicate of https://github.com/prisma/prisma/issues/2942 and https://github.com/prisma/graphql-playground/issues/846.