Messages duplicated when using phoenix_pubsub_redis as adapter

[thiamsantos]

Whenever I published a message on a subscription it always publishes two messages instead of one. It only happens when the phoenix_pubsub_redis adapter is used for the pubsub. If I use the PG2 adapter the errors stops from happening.

Using Redis as backend we have two messages been published:

Using PG2 we have only one.

The expected behaviour would be only one message been published.

I don't know if it is a issue with absinthe or with the redis adapter, but is a really strange behaviour.

I created a bootstrap phoenix project with the minimal to simulate the behaviour.

Versions:

Elixir version: 1.9.1
OTP version: 21.1.1

Deps:

{:phoenix, "~> 1.4.9"},
{:phoenix_pubsub, "~> 1.1"},
{:gettext, "~> 0.11"},
{:jason, "~> 1.0"},
{:plug_cowboy, "~> 2.0"},
{:absinthe_plug, "~> 1.4"},
{:absinthe_phoenix, "~> 1.4"},
{:phoenix_pubsub_redis, "~> 2.1"}

[thiamsantos]

I did some investigation around this issue, and seems that the problem is been caused by this line. https://github.com/absinthe-graphql/absinthe/blob/master/lib/absinthe/subscription.ex#L83

The call to publish_remote already publishes the data to redis, and the local publish also publishes to redis. In my case, calling publish_remote/3 directly solved the issue, but I don't like very much relying on a internal function.

I would like to understand why we have this two publishes, one to remote and another to local, as when we use the redis adapter both publishes are "remote". It is something specific to a PG2 adapter? What should be the prefered approach for this? cc: @benwilson512 @bruce

[benwilson512]

Hi @thiamsantos. I'll go into more detail tomorrow, but I think the real issue is this line here: https://github.com/absinthe-graphql/absinthe/blob/master/lib/absinthe/subscription/proxy.ex#L36. Phoenix PubSub doesn't provide a way to say "publish to every node that isn't this one", so I have to publish to every node, including this one, and then filter out messages that come from the current node. However my mechanism for doing so relies on a detail of how PG2 works, I should be using the Phoenix.Endpoint.node_name or whatever it's called.