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)
@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.
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
We found out, that subscriptions currently don't fire when the input arguments are provided as variables to Prisma.
subscription ($_where: PostSubscriptionWhereInput!) {
post(where: $_where) {
node {
id
}
}
}
{
"_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.
Most helpful comment
Any progress for where subscriptions?