Prisma1: Subscriptions or server side subscriptions with where filter don't work

Created on 25 Jan 2018  ·  41Comments  ·  Source: prisma/prisma1

git clone [email protected]:graphcool/prisma.git
cd prisma/examples/subscriptions
git checkout e0eb96d4b02c2b3cb04ca23c4a8693a72c91eaf8
yarn
yarn prisma deploy
yarn start

activate subscription:

subscription {
  publications {
    node {
      id
      title
      text
    }
  }
}

create post:

mutation {
  writePost(title: "test") {
    id
  }
}

Note that no event is published. Server logs also show error messages. If you change src/index.js to

  Subscription: {
    publications: {
      subscribe: async (parent, args, ctx, info) => {
-        return ctx.db.subscription.post({where: {mutation_in: ['CREATED']}}, info)
+       return ctx.db.subscription.post({ }, info)
      },
    },
  },

everything works as expected.

local logs:

prisma-database_1  | Variable '$_where' expected value of type 'PostSubscriptionWhereInput' but got: {"mutation_in":["CREATED"]}. Reason: 'mutation_in' Field 'mutation_in' is not defined in the input type 'PostSubscriptionWhereInput'. (line 1, column 15):
prisma-database_1  | subscription ($_where: PostSubscriptionWhereInput) {
prisma-database_1  |               ^
prisma-database_1  |    at sangria.execution.ValueCollector.getVariableValues(ValueCollector.scala:37)
prisma-database_1  |    at sangria.execution.Executor.$anonfun$execute$2(Executor.scala:89)
prisma-database_1  |    at scala.util.Success.flatMap(Try.scala:247)
prisma-database_1  |    at sangria.execution.Executor.execute(Executor.scala:88)
prisma-database_1  |    at sangria.execution.Executor$.execute(Executor.scala:199)
prisma-database_1  |    at com.prisma.subscriptions.SubscriptionExecutor$.execute(SubscriptionExecutor.scala:104)
prisma-database_1  |    at com.prisma.subscriptions.resolving.SubscriptionResolver.executeQuery(SubscriptionResolver.scala:93)
prisma-database_1  |    at com.prisma.subscriptions.resolving.SubscriptionResolver.handleDatabaseCreateEvent(SubscriptionResolver.scala:65)
prisma-database_1  |    at com.prisma.subscriptions.resolving.SubscriptionResolver.handleDatabaseMessage(SubscriptionResolver.scala:58)
prisma-database_1  |    at com.prisma.subscriptions.resolving.SubscriptionResolver.$anonfun$handleDatabaseMessage$3(SubscriptionResolver.scala:47)
prisma-database_1  |    at akka.pattern.FutureTimeoutSupport.liftedTree1$1(FutureTimeoutSupport.scala:25)
prisma-database_1  |    at akka.pattern.FutureTimeoutSupport.$anonfun$after$1(FutureTimeoutSupport.scala:25)
prisma-database_1  |    at akka.actor.Scheduler$$anon$4.run(Scheduler.scala:140)
prisma-database_1  |    at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:40)
prisma-database_1  |    at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(ForkJoinExecutorConfigurator.scala:43)
prisma-database_1  |    at akka.dispatch.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
prisma-database_1  |    at akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
prisma-database_1  |    at akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
prisma-database_1  |    at akka.dispatch.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
aresubscriptions bu2-confirmed areprisma

Most helpful comment

Any progress for where subscriptions?

All 41 comments

@marktani meanwhile the tutorial should be fixed I think https://www.howtographql.com/graphql-js/6-subscriptions/

I updated the tutorial (https://www.howtographql.com/graphql-js/6-subscriptions/)
Here is the issue if someone wants to accept it howtographql/howtographql#475

Thanks a lot @supergoat 🙌

@marktani is there a resolution to this?

I've encountered in issue with subscriptions and fragments... If my subscription query relies on a fragment, it doesn't get fired:

const MESSAGES_SUBSCRIPTION = gql`
  subscription message($classroomId: ID!) {
    message(classroomId: $classroomId) {
      node {
        id
        text
        createdAt
        sender {
          id
          name
          username
        }
        # ...ChatMessageMessage
      }
    }
  }
`
// ${ChatMessage.fragments.message}

That same fragment is used successfully on my initial query for all messages.

Hey @hoodsy, the originally posted issue has not yet been resolved.

Please provide a reproduction of the issue you encountered in a new bug report, as that's a separate discussion. 🙂

Thanks @supergoat

Is this issue fixed? Might have a go at fixing it @marktani

Does this means where filter doesn't work on server side with ctx.db.subscription.post({where: {mutation_in: ['CREATED']}}, info)?
But still works on client side query with ctx.db.subscription.post({ }, info) this fix one server side?

@oiojin831, this means that ctx.db.subscription.post({where: {mutation_in: ['CREATED']}}, info) doesn't work between your application server and a Prisma instance. The connection between your application server and your client is not impacted by this.

@marktani Thanks for the clarification 😄

Any progress for where subscriptions?

This has been confirmed to also affect server-side subscriptions: https://github.com/graphcool/prisma/issues/2109.

@tfiwm, we are still working on a fix for this 🙂

So does this mean that subscriptions are pretty much unusable? Or to be more precise all filtering has to be done in the application code? In that case, can someone point me in a direction how to chew on that AsyncIterator thing?

  Subscription: {
    publications: {
      subscribe: async (parent, args, ctx, info) => {
        const iterator = await ctx.db.subscription.post({ }, info)
        // how send only a filtered posts (based on args) to client?
      },
    },
  },

Edit: Ah, this is what I was looking for :) https://github.com/graphcool/prisma-binding/issues/78

Server side subscriptions with filters should now correctly trigger: https://github.com/graphcool/prisma/issues/2169.

@marktani That's great news! Although I have a trouble finding information on how to upgrade this. I mean for a local cluster I've run prisma local upgrade, but what about the one in Prisma Cloud? Will it get updated automatically?

You will soon be able to upgrade the cluster from within the Prisma Console: https://github.com/graphcool/prisma-cloud-feedback/issues/33.

If I am back from holidays i will try it immediately. I can finally deactivate the polling

Note that filters for websocket subscriptions still don't work, as far as I know. The fix was only about "server side subscriptions", which are setup in prisma.yml and triggered by an HTTP webhook.

Oh, that was confusing, oh well, back to waiting :)

I just tested where filters in websocket subscriptions and they seem to be working as expected. Since websocket and serverside subscriptions share the same filter logic I am assuming that our fix in #2169 fixed both. Sorry for the confusion.

bildschirmfoto 2018-04-12 um 13 42 40

Please let us know if you are still running into filter issues.

I am currently working through the tutorial - https://www.howtographql.com/graphql-js/7-subscriptions/ - and it looks like the issue with filtering in websocket subscriptions still exists. I have prisma-binding 1.5.17 installed. Apologies if I am missing something.

I have to use this workaround to get the example to work in the playground.

function newLinkSubscribe (parent, args, context, info) {
  return context.db.subscription.link({ }, info)
}

Yes i can confirm this. It is still not working!

subscribe: (parent, args, ctx: Context, info) => {
      const userId = getUserId(ctx);
      const db = ctx.db;

      return db.subscription.test(
        {
          where: {
            mutation_in: ['CREATED', 'DELETED']
          }
        },
        '{ mutation }'
      );
    }

I have the latest version:

"graphql-cli": "2.15.9",
"nodemon": "1.17.3",
"npm-run-all": "4.1.2",
"prisma": "1.6.0",
"prisma-binding": "1.5.17",
"graphql-subscriptions": "0.5.8",
"graphql-yoga": "1.8.5",

Same issue here. Also, it appears that even without using any filters, update subscriptions are NEVER fired. Any progress on solving this? Has been around for a while.

I have same issue when going through the Learn GraphQL https://www.howtographql.com/graphql-js/7-subscriptions/ using "prisma-binding": "^1.5.17"

It seems that my UPDATED mutation also never gets triggered, even though I properly have the entry updated from another tab. Same problem of not being triggered, whether I run the subscription directly in the Prisma API or on http://localhost:4000

I should say that I'm running Prisma 1.6.0. Output of prisma cluster list :

name        version  endpoint
──────────  ───────  ─────────────────────────────
local       1.6.0    http://localhost:4466/cluster
prisma-eu1  1.6.0    https://eu1.prisma.sh/cluster
prisma-us1  1.6.0    https://us1.prisma.sh/cluster

subscription is killing me too :(

Testing a fix internally at the moment, we'll release a patched version (presumably 1.6.1) as soon as we are ready.

Fix is released in Prisma 1.6.1, please give it a spin and report back if you still face issues. Thanks!

Well, UPDATED mutation subscription now works for me. But it's not 1.6.1 that I have pulled, instead, it's 1.6.2:

$ prisma cluster list
name        version  endpoint
──────────  ───────  ─────────────────────────────
local       1.6.2    http://localhost:4466/cluster
prisma-eu1  1.6.1    https://eu1.prisma.sh/cluster
prisma-us1  1.6.1    https://us1.prisma.sh/cluster

I can confirm that the following work on 1.6.2:

Websocket subscription:

      const QUERY = `
        subscription user {
          user(where: {
            mutation_in: [CREATED]
          }) {
            mutation
            node {
              id
              name
            }
            updatedFields
            previousValues {
              id
            }
          }
        }
      `

server side subscription (webhooks):

    query: |
      subscription {
        user(where: {mutation_in:[CREATED, UPDATED, DELETED]}) {
          mutation
        }
      }

Can anyone still reproduce this? 🙂

Hi @marktani I still seem to be experiencing the issue and have upgraded to prisma 1.6.2. I have noticed an error in the cluster logs listed below, does this shed some light on the issue?

prisma-database_1 | Variable '$_where' expected value of type 'LinkSubscriptionWhereInput' but got: {"mutation_in":["CREATED"]}. Reason: 'mutation_in' Field 'mutation_in' is not defined in the input type 'LinkSubscriptionWhereInput'. (line 1, column 15): prisma-database_1 | subscription ($_where: LinkSubscriptionWhereInput) {

Here is a link to my repo which has the error for reference: https://github.com/lucased/prisma-hackernews

local       1.6.2    http://localhost:4466/cluster
prisma-eu1  1.6.1    https://eu1.prisma.sh/cluster
prisma-us1  1.6.1    https://us1.prisma.sh/cluster

@lucased Don't use string for mutation_in filter, it's enum there. Look closely at @marktani example above. Although the error message is somewhat weird, I might be wrong here.

Thanks @lucased - you are describing the usage with prisma-binding. I can confirm that this is still problematic, see https://github.com/graphcool/prisma-binding/issues/139. Can you confirm that directly to the Prisma API works, however?

@FredyC, when writing queries/mutations in JavaScript, you need to use strings for enums, otherwise it is incorrect JavaScript because the symbol CREATED is not known, for example.

Hi @marktani thanks for confirming this, I've tested subscriptions directly with the Prisma API and can confirm CREATED, UPDATED & DELETED filters now work. Cheers

Update

We found out, that subscriptions currently don't fire when the input arguments are provided as variables to Prisma.

query

subscription ($_where: PostSubscriptionWhereInput!) {
  post(where: $_where) {
    node {
      id
    }
  }
}

variables

{
  "_where": {
    "mutation_in": [
      "CREATED",
      "UPDATED"
    ]
  }
}
 Variable '$_where' expected value of type 'PostSubscriptionWhereInput!' but got: {"mutation_in":["CREATED","UPDATED"]}. Reason: 'mutation_in' Field 'mutation_in' is not defined in the input type 'PostSubscriptionWhereInput'. (line 1, column 15):
prisma_1  | subscription ($_where: PostSubscriptionWhereInput!) {
prisma_1  |               ^
prisma_1  |     at sangria.execution.ValueCollector.getVariableValues(ValueCollector.scala:37)
prisma_1  |     at sangria.execution.Executor.$anonfun$execute$2(Executor.scala:89)
prisma_1  |     at scala.util.Success.flatMap(Try.scala:247)
prisma_1  |     at sangria.execution.Executor.execute(Executor.scala:88)
prisma_1  |     at sangria.execution.Executor$.execute(Executor.scala:199)
prisma_1  |     at com.prisma.subscriptions.SubscriptionExecutor$.execute(SubscriptionExecutor.scala:110)
prisma_1  |     at com.prisma.subscriptions.resolving.SubscriptionResolver.executeQuery(SubscriptionResolver.scala:79)
prisma_1  |     at com.prisma.subscriptions.resolving.SubscriptionResolver.handleDatabaseCreateEvent(SubscriptionResolver.scala:61)
prisma_1  |     at com.prisma.subscriptions.resolving.SubscriptionResolver.handleDatabaseMessage(SubscriptionResolver.scala:54)
prisma_1  |     at com.prisma.subscriptions.resolving.SubscriptionResolver.$anonfun$handleDatabaseMessage$3(SubscriptionResolver.scala:44)
prisma_1  |     at akka.pattern.FutureTimeoutSupport.liftedTree1$1(FutureTimeoutSupport.scala:25)
prisma_1  |     at akka.pattern.FutureTimeoutSupport.$anonfun$after$1(FutureTimeoutSupport.scala:25)
prisma_1  |     at akka.actor.Scheduler$$anon$4.run(Scheduler.scala:140)
prisma_1  |     at akka.dispatch.TaskInvocation.run(AbstractDispatcher.scala:40)
prisma_1  |     at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(ForkJoinExecutorConfigurator.scala:43)
prisma_1  |     at akka.dispatch.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
prisma_1  |     at akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
prisma_1  |     at akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
prisma_1  |     at akka.dispatch.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

Can confirm this problem:

prisma-database_1  | Variable '$_where' expected value of type 'VariationSubscriptionWhereInput' but got: {"mutation_in":["CREATED","DELETED"],"node":{"test":{"project":{"users_some":{"id":"cjdi45vly5pb00122mwasazmd"}}}}}. Reason: 'mutation_in' Field 'mutation_in' is not defined in the input type 'VariationSubscriptionWhereInput'. (line 1, column 15):
prisma-database_1  | subscription ($_where: VariationSubscriptionWhereInput) {

We fixed GraphQL variable support for subscriptions in https://github.com/graphcool/prisma/pull/2244, and released it in 1.7.0. This should fix all known problems with subscriptions and server side subscriptions.

Please open a new issue if you are still encountering a problem 🙂

Can agree!! Finally it is working! THX!!

@marktani I found one last thing! If i use a fragment inside my subscription query on client side the server returns directly a response and closes the subscription connection.

Thanks @tfiwm, this is being discussed here: https://github.com/graphcool/prisma/issues/2026.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

wereHamster picture wereHamster  ·  37Comments

schickling picture schickling  ·  44Comments

marktani picture marktani  ·  35Comments

marktani picture marktani  ·  34Comments

sorenbs picture sorenbs  ·  48Comments