-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
graphql-subscriptions is not working consistently. #187
Comments
Would it be possible for you to provide a runnable example of the issue? It's kind of vague right now... |
Hi @grantwwu , thank you for your fast answer. Connection to WS
|
Having this same issue, sometimes the subscription just doesn't trigger on the app end |
Hi @svrpeakers, thanks for your reply. |
We had something similar. Everything worked local, but not on production. |
So yes, my issue ended up being we weren't' closing subscriptions when we closed the component. So we would keep opening new subscriptions and the server couldn't manage all the subscriptions. (all the subscriptions came in the same socket) |
@svrpeakers It sounds very reasonable and I think this is the same problem in our project. @JonathanCA97 Good point, we've experienced it too. |
We still have strange issues here in production causing from memory-leaks (using Websockets) and gentleman, it is really not a pleasure to fix such a problem. We ended up by making use of polling as a first hot fix, furthermore we have noticed same strange behaviour in our connector implementation axelspringer/graphql-google-pubsub#16. Contributors are scratching behind their heads, developers are catching after ghosts. From our side, we do not trust the whole async iterator stuff at the moment. |
so yeah, we also still have this issue in production, closing subscriptions helped but didn't resolve the problem completely. we also had to add a polling option to our production app. |
having the same issue.... |
We have same issue in production with the following stack:
Redis & apollo server are on separate VMs. |
I am having the same issue. Are there any fallback mechanisms that I would be able to implement to refrain this from happening or this is not the correct use case for reliable messaging? |
maybe we have the same root cause, how you fixed this??? |
I am finding that when running locally behind an ngrok tunnel and using the When I push my code to an Elastic Beanstalk, queries and mutations will work fine, but clients are not notified of events. On the server, I use the Would welcome any advice on how to fix this. |
hi @andrew-ironforge @vladoro did you solved your problem?
Same occurs whe using wss. + |
@mogarick no I never fixed my problem. I think we are having different issues though because your URL does not look valid. |
Sorry @andrew-ironforge , it looks the url got lost in formatting. the url is for example So what did you do? changed from RedisPubsub lib to other one or something? |
@mogarick I never actually figured it out. When I ran my API locally, subscriptions would work fine, but ceased to work when running in a docker container on the elastic beanstalk. It might also be important to note that the client is an iOS application; however I don't believe this matters. |
Same problem here, subscriptions are not working properly. I just added a new collection that manages comments on my project, but I can't find a way to make it work properly. I also tried to remove all the other subscriptions to see if there are too many of them, but nothing changes |
having the same issue on AWS. using multiple instances and it works perfectly local but not in production. Using import { RedisPubSub } from 'graphql-redis-subscriptions';
import Redis from 'ioredis';
const options = {
host: process.env.REDIS_HOST,
port: process.env.REDIS_PORT,
password: process.env.REDIS_PASSWORD,
retryStrategy: times => {
return Math.min(times * 50, 2000);
}
};
const pubsub = new RedisPubSub({
publisher: new Redis(options),
subscriber: new Redis(options)
});
export default pubsub; the error I see in the playground:
|
Also having the same issue where subscriptions work fine locally, but don't update over wss... |
Same here with PM2 cluster mode and |
August 11, 2020: Did anyone ever figured this? It used to work well (sometimes) but has currently stopped working for the chat section of my app, even on local. |
It's very weird, it used to work well here, too, on both production and local. But a couple of weeks ago, it broke on one of my production servers, and on my dev environment. My client will say "connected" but I receive no messages. And if I subscribe through apollo's Playground, I get the following message:
but chrome stays connected, and inspecting the network request, I see that I continue to receive @Dajust can you please check if you get the same error message? I don't understand how something can break on its own. My resolver, just in case: resolvers: {
Subscription: {
...,
Test: {
subscribe: () => redis.asyncIterator("TEST"),
resolve: (testString) => testString
},
},
}
edit: weirdly enough, it works on local. Same code, same dependencies (I didn't mock redis, just ran a local redis db, I didn't mock anything). |
I stumbled upon the same problem yesterday. I'm using apollo-server locally so, to provide https with certbot to the "outside" I am using dmz + nginx as a proxy server. When using this configuration subscriptions didn't work at all, while, instead, everything worked fine with ngrok! After some research it turns out one has to configure nginx (or whatever proxy server/http server) to handle the websocket protocol (it can be handled via http/s either, but it has to be configured anyways). In my case, adding these lines to nginx.conf solved the problem: `
` I hope this helps. |
Okay so I sort of found out what my issue was, and it wasn't headers. Strangely, node version seems to have been the culprit. Locally I was working with It's slightly confusing though because I found where the function that throws the error above (https://github.com/graphql/graphql-js/blob/master/src/subscription/subscribe.js#L287) and how they determine whether an object is an async iterator or not (https://github.com/graphql/graphql-js/blob/35f6df8693eaf9f484df8566f752a515aee4893b/src/jsutils/isAsyncIterable.js#L11). I'm not a js developer so I don't know what any of this means, but it's working now after explicitly setting node to Very scientific analysis, I know. |
Same Issue here. |
Any Progress here? |
Any Progress here? |
Any progress? I wonder if there is any workaround while we wait for the problem to be solved? |
Bumping this up as we are experiencing similar behaviour with some of the clients missing subscription messages without a reproducible pattern. |
Our team gave up on waiting for a fix here and made the switch to |
Did you solved your problem? I'm facing the same issue, only in local subscriptions working fine for me. |
If Person A has a socket connection to Container A, Person B has a socket connection to Container B, and Person A sends Person B a message, how does that message get routed to Container B if Container A only knows about its own connections? The answer is using a Pub/Sub service that lives outside of the docker containers like Cloud Pub/Sub or Redis Pub/Sub that allows the Containers to send messages to each other so they can notify any clients that may need that message. The Pub/Sub from this package will only work locally with 1 running instance of your graphql server since it's just using node event emitter. |
Any Progress here? |
Did anyone find any solution?. I am having the same issue.Every thing fine in local, But not in production (AWS) |
Note that the default PubSub implementation is intended for demo purposes. It only works if you have a single instance of your server and doesn't scale beyond a couple of connections. For production usage you'll want to use one of the PubSub implementations backed by an external store. (e.g. Redis) - from graphql-subscriptions doc |
Hi @skjorrface , it is work well for me thank you |
Any Progress here? |
Hi all,
We are using PubSub in our application in this manner:
When deletion event is arriving into server:
pubsub.publish('onDeleteItem', {onDeleteItem: [msg.payload.ItemId]});
Resolvers:
Subscription: { onDeleteItem: { subscribe: () => pubsub.asyncIterator('onDeleteItem'), }, },
Subscribing to it from our client side:
const onDeleteItemSubscription = gql
;
The problem is that sometimes the subscription is working fine and the deleted item is filtered as expected, but very often it just not working at all. There are no error logs.
When I debug it, I can see that the problem is that the client is not notified by pubsub.publish()
The problem is occurring with all our subscriptions and this is only one example of them.
What am I missing here?
Thanks.
The text was updated successfully, but these errors were encountered: