Unable to find subscription with identifier: {"channel":"GraphqlChannel","channelId":"18bccb1dbd6"} about graphql-ruby HOT 5 OPEN

Actually, this being raised in subscriptions.rb when the identifier can't be found in the @subscriptions array, could this be because we run multiple containers, and the user may be subscribed at another container?

from graphql-ruby.

Hi! Sorry for the trouble and thanks for the detailed report. What I expect on re-deploy is for clients to reconnect, re-sending GraphQL subscriptions as needed. A couple of quick thoughts:

• What caused this error to start occurring? Did you just add GraphQL subscriptions to your app, or did something else change that caused these to appear?
• Reviewing the backtrace above, I don't see anything GraphQL-related. Is there any indication that this is GraphQL-specific? (Are there other uses of ActionCable that work properly in your application?)
• You mention that you can't replicate the error locally. If you're using the app in production during a deploy, do you see anything happening in your browser?
• In AppSignal, can you see any trends in the occurences in this bug? (Maybe browser? I can imagine browsers handling this event in different ways...)

from graphql-ruby.

@rmosolgo Right, so to address your questions (and what I think is going on here as well):

1. This error has been occurring for a very long time for us, but it doesn't seem to cause any issues. We've had a lot of ideas on what it could be, and none of those have turned out to be it. We haven't really prioritized it because like I said, it seems pretty harmless
2. You're right, and I realized after posting this here that this may not be graphql-related and could be actioncable-related
   3 & 4. We're not seeing anything related to the browser type for this, seems to be a mixed bag

I think it's that we have this in our GraphQLChannel:

def subscribed
    @subscription_ids = []
end

This would start each instance on a blank slate of connections, so if we're scaling and running 3-4 instances, they're all pushing to the same redis. One instance may pick up a subscriptions.trigger(...) from puma on another instance, but doesn't have the gid in its @subscription_ids, because its not being shared.

Perhaps @subscription_ids should be pointing to redis to maintain a shared list of subscribed clients?

from graphql-ruby.

My intention on @subscription_ids is for that to be a per-instance list of subscribers to that instance. So it works like:

• subscriptions.trigger is called in one Ruby process, it calls .broadcast to notify other processes of the trigger:

  graphql-ruby/lib/graphql/subscriptions/action_cable_subscriptions.rb

  Lines 116 to 122 in 8270480

  	# An event was triggered; Push the data over ActionCable.
  	# Subscribers will re-evaluate locally.
  	def execute_all(event, object)
  	stream = stream_event_name(event)
  	message = @serializer.dump(object)
  	@action_cable.server.broadcast(stream, message)
  	end

• meanwhile, any ActionCable process that received a subscription should have setup a stream_from for that subscriber:

  graphql-ruby/lib/graphql/subscriptions/action_cable_subscriptions.rb

  Line 169 in 8270480

  channel.stream_from(stream_event_name(initial_event), coder: @action_cable_coder) do |message|

• So, when a process receives a notification from a trigger, it runs that stream_from block and generates a payload. Then it broadcasts again, using the specific subscription ID, to update the client:

  graphql-ruby/lib/graphql/subscriptions/action_cable_subscriptions.rb

  Line 129 in 8270480

  @action_cable.server.broadcast(stream_subscription_name(subscription_id), payload)

I hope that helps!

from graphql-ruby.

@rmosolgo Thank you for taking the time out of the day to explain this a bit, appreciate it! :) We still haven't worked this issue out. We realized we weren't running ActionCable standalone in production, and thought perhaps this would be solved when we move ActionCable to be its own standalone service, but (I presume) because we also scale this out, this "issue" still persists.

We don't really know to what extent its an issue, or if it is an issue at all — e.g, are we getting a certain percentage of lost websockets pushes? or are these errors completely harmless?

So, when a process receives a notification from a trigger, it runs that stream_from block and generates a payload. Then it broadcasts again, using the specific subscription ID, to update the client

In this sense, should an ActionCable process that does not have the subscription_id in its list of subscribers simply not pick this up? Do you see a way that it would happen in a multi-ActionCable setup that ActionCable processes routinely try to handle messages meant for subscriber_ids that they dont have?

from graphql-ruby.