Skip to content

Conversation

@thlacroix
Copy link

Since the upgrade to the 1.3.0 version of this lib, we noticed "No query string was present" errors received on our graphql subscription clients; caused by https://github.com/rmosolgo/graphql-ruby/blob/v2.5.4/lib/graphql/subscriptions.rb#L106 receiving a hash with an nil query_string instead of receiving nil directly.

This comes from this change (the return makes read_subscription return nil, while next only causes the block to early return): 81c3c4c#diff-4e11ab0cfb2b97d55c90a6b52d3c59dcc0c649422f3ad1b1e9e30fe8a06bc6fdR163
This PR reverts this small change to handle this case more properly.

I've found however that this still masks a race condition (between finding an existing subscription_id for a fingerprint and reading it, it might have been expired / deleted, which explains why we get these errors; however this prevents other subscriptions from the same fingerprint to receive their notification), but I'll open a separate issue.

:query_string, :variables, :context, :operation_name
).tap do |subscription|
next if subscription.values.all?(&:nil?) # Redis returns hash with all nils for missing key
return if subscription.values.all?(&:nil?) # Redis returns hash with all nils for missing key
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like tests fail due to this return (and RuboCop is not happy).

Let's refactor to use .then { |subscription| next if ..; ...; subscription }

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've pushed a new commit using then instead of tap

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants