Enum with custom values aren't working as expected to trigger subscriptions #4713
Comments
|
Here's a reproducible spec: # frozen_string_literal: true
require "spec_helper"
module SubscriptionEnum
class InMemoryBackend < GraphQL::Subscriptions
attr_reader :write_subscription_events, :execute_all_events
def initialize(...)
super
@write_subscription_events = []
@execute_all_events = []
end
def write_subscription(_query, events)
@write_subscription_events.concat(events)
end
def execute_all(event, _object)
@execute_all_events.push(event)
end
end
class MyEnumType < GraphQL::Schema::Enum
value "ONE", value: "one"
value "TWO", value: "two"
end
class MySubscription < GraphQL::Schema::Subscription
argument :my_enum, MyEnumType, required: true
field :my_enum, MyEnumType
end
class SubscriptionType < GraphQL::Schema::Object
field :my_subscription, resolver: MySubscription
end
class Schema < GraphQL::Schema
subscription SubscriptionType
use InMemoryBackend
end
end
describe GraphQL::Subscriptions do
describe "enums" do
let(:schema) { SubscriptionEnum::Schema }
let(:implementation) { schema.subscriptions }
let(:write_subscription_events) { implementation.write_subscription_events }
let(:execute_all_events) { implementation.execute_all_events }
describe "pushing updates" do
focus
it "sends updated data" do
query_str = <<-GRAPHQL
subscription ($myEnum: MyEnum!) {
mySubscription (myEnum: $myEnum) {
myEnum
}
}
GRAPHQL
schema.execute(query_str, variables: { "myEnum" => "ONE" })
schema.subscriptions.trigger(:mySubscription, { "myEnum" => "ONE" }, nil)
assert_equal(":mySubscription:myEnum:one", write_subscription_events[0].topic)
assert_equal(":mySubscription:myEnum:one", execute_all_events[0].topic)
end
end
end
end |
|
It fails with: |
|
That's how we fixed it for our current version: # Normalize enum values to its custom value when triggering subscriptions.
#
# In a nutshell, Event#topic normalizes "ENUM_VALUE" to "enum_value" when
# writing a subscription while when triggering it doesn't.
#
# This monkey-patch will allow us to call either way:
#
# RootSchema.subscriptions.trigger(:my_subscription, my_enum: "enum_value")
# RootSchema.subscriptions.trigger(:my_subscription, my_enum: "ENUM_VALUE")
#
# See https://github.com/rmosolgo/graphql-ruby/issues/4713
module NormalizeTriggerSubscriptionEnumValues
def stringify_args(arg_owner, args, context)
result = super
if arg_owner.is_a?(Class) && arg_owner < GraphQL::Schema::Enum
arg_owner.coerce_isolated_input(result) || result
else
result
end
end
end
GraphQL::Subscriptions::Event.singleton_class.prepend(NormalizeTriggerSubscriptionEnumValues) |
|
Hey, sorry for the trouble and thanks for the great report and work-around! I bet a patch very similar to what you shared will fix this in the gem. I'll take a look soon, or feel free to submit a PR if you're interested 👍 |
rmosolgo
added a commit
that referenced
this issue
Nov 30, 2023
Fix triggering with custom enum value, fixes #4713
|
Thanks @rmosolgo ! ❤️ |
rmosolgo
added a commit
that referenced
this issue
Dec 8, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When a subscription is created,
event.topicrepresents the enum value as the custom value.When the subscription is triggered,
event.topicrepresents the enum value as the given value, which doesn't map to the original topic therefore not encountering the subscription and not triggering it.Looks like values are normalized to write the subscription but not for triggering it!
Versions
graphqlversion: 1.13.19 (legacy app but tried the latest version and seems to behave as the same)rails: 6.1.7.5 (doesn't seem related to rails)GraphQL schema
Include relevant types and fields (in Ruby is best, in GraphQL IDL is ok). Any custom extensions, etc?
GraphQL query
Example GraphQL query and response (if query execution is involved)
Steps to reproduce
Expected behavior
The subscription would update as expected (by having the same event.topic between write_subscription and execute_all).
Actual behavior
I added some
binding.pryin our app intowrite_subscriptionandexecute_all.Calling
event.topicreturns like this forwrite_subscription:And like this for
execute_all:Therefore they don't match and we can't find the subscription.
Additional context
Tried adding
prepareto the argument butprepareis only called when writing subscription and not for triggering it, i.e.:Not sure if that was intended, it's not our use case but we tried to use it to normalize the values across write and trigger as workaround.
PS: We are using a custom middleware to write/read/trigger/etc subscriptions but nothing in special there that could case
event.topicto behave differently from the gem.The text was updated successfully, but these errors were encountered: