Unable to find subscription with identifier: {"channel":"GraphqlChannel"} (RuntimeError) #5086
Comments
|
Hey, thanks for sharing all these details. Here are some additional points I can glean from the backtrace:
So, I think it's some weirdness with unsubscribing. In the library, it could be this code which might make it send "unsubscribe" multiple times: graphql-ruby/lib/graphql/subscriptions/action_cable_subscriptions.rb Lines 226 to 227 in dda906b For context, do any of your subscriptions terminate with |
No. We don’t call that, or otherwise terminate subscriptions, anywhere on the backend. Here’s how we manage subscriptions from the frontend, abridged and simplified to omit irrelevant details:
import * as ActionCable from "@rails/actioncable";
import createRelaySubscriptionHandler from "graphql-ruby-client/subscriptions/createRelaySubscriptionHandler";
import { Environment, Network, RecordSource, Store } from "relay-runtime";
const cable = ActionCable.createConsumer("/cable");
const subscriptionHandler = createRelaySubscriptionHandler({ cable });
const environment = new Environment({
network: Network.create(fetchQuery, subscriptionHandler),
store: new Store(new RecordSource())
});
import { graphql, requestSubscription } from "react-relay";
const subscription = graphql`
subscription newLogSubscription($storyId: ID!) {
newLog(storyId: $storyId) {
…
}
}
`;
export const newLogSubscription = (variables) => requestSubscription(environment, {subscription, variables})
useFocusedSubscriptions(
() => [newLogSubscription({storyId: props.storyId})],
[props.storyId]
);
useEffect(() => {
const subscriptions = getSubscriptions()
return () => {
subscriptions.forEach((subscription) => subscription.dispose())
}
})I'm not 100% sure what code path the |
|
Hey, thanks for following up on this. Everything there certainly looks good to me. I've been working on improving GraphQL-Ruby's tests for ActionCableSubscriptions but got a bit stuck (https://stackoverflow.com/questions/78999661/why-doesnt-this-actioncable-broadcast-work-in-test). I'm hoping that once I get the suite running, I can replicate this issue in test and really fix it! |
|
Hey, I've continued to investigate this but working through it server-side didn't give me any leads :S I've worked up a change which will disable double-unsubscribes: #5109. Do you think you could copy that into your project and see if it makes this problem go away? (I expect it won't help, because I can't find any mechanism that would cause |
|
On it! |
|
Hey there, we tried this out in production for approximately 24 hours, but it didn't resolve the exception we're seeing. I feel like you've gone above and beyond here already… I think we should try monkeypatching a few things on our end next to see if we can isolate the problem further. It feels to me like this could even be a problem within ActionCable itself. |
|
Bummer ... I'm sorry to hear it didn't make a difference.
I pondered that too, but afaict, nobody has encountered this outside the GraphQL-Ruby world. Do you see any evidence of it out there? Another possibility for debugging further would be to replicate it in a sample app. But then again, we don't know what actually causes it, do we? 😖 |
Describe the bug
Breaking this out of a discussion on a similar issue, #4702.
Very frequently – around a thousand times per day – we see this issue fire in Sentry in production. It's not clear if this aligns with user-facing defects, although we do hear occasional reports of real-time features unexpectedly stopping working until refresh.
Versions
GraphQL schema
Our subscriptions are handled by ActionCable:
We have a straightforward implementation of
GraphqlChannel, following https://graphql-ruby.org/api-doc/2.0.14/GraphQL/Subscriptions/ActionCableSubscriptions.html.The frontend is powered by Relay, following the ActionCable guide in https://graphql-ruby.org/javascript_client/relay_subscriptions.
GraphQL query
We see these for various subscription queries, here's a random example:
Steps to reproduce
Unfortunately, I haven't found a way to reproduce the problem, even when I modify our client-side code to repeatedly dispose of a subscription, as discussed here: #4702 (comment).
Expected behavior
No exception.
Actual behavior
Here's the full stack trace we see, which appears to match #4702.
Click to view exception backtrace
The text was updated successfully, but these errors were encountered: