subscription with fragments does not fire properly

canercandan commented 6 years ago

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 commented 6 years ago

+1 I have the same issue.

divyenduz commented 6 years ago

I am also able to replicate this issue.

lowsky commented 6 years ago

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 {
    <rejected> TypeError: Cannot read property 'variableDefinitions' of undefined
at Object.<anonymous> (//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 (<anonymous>)
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.<anonymous> (//node_modules/prisma-binding/dist/src/Handler.js:54:36)
at formatValue (util.js:430:38)
at formatProperty (util.js:831:11) },
 mutation: Promise {
    <rejected> TypeError: Cannot read property 'variableDefinitions' of undefined
at Object.<anonymous> (//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 (<anonymous>)
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.<anonymous> (//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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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] commented 6 years ago

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 commented 6 years ago

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

samdenty commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@divyenduz

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

What I found:

A subscription with a name AND a fragment executed against the graphql-yoga does NOT return null anymore
But instead it now returns the following error "TypeError : Cannot read property 'post' of undefined" AND the socket is still closed
However when executing the same subscription against the prisma endpoint it works as expected
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 commented 6 years ago

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

While prisma-bindings@2.1.4 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] commented 5 years ago

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 commented 5 years ago

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

prisma / prisma1

subscription with fragments does not fire properly #2026