Postgres Subscriptions - `listen` should only happen in graphql projects

Is there an existing issue for this?

• I have searched the existing issues

Product

Hot Chocolate

Describe the bug

We run background jobs as well as api servers. We have recently rolled out HotChocolate Subscriptions using the Postgres Backplane.

A curious scenario that occurred over the weekend was a backend server processed an event that was published into the postgres backplane. This however triggered the subscription system to begin listening to events. The listening system is designed to run a task forever receiving events from the postgres connection notification event. This means that the task processing the event in the backend never finished as it had somehow triggered the listen command.

I'm not sure how this happened yet. The timing of this event does correlate with process startup so there may be some race condition that meant the subscription wasn't initialised fully before a message was published and so was initialised by its first use and that somehow meant it ended up owning the long running task.

In a previous issue/pr i have contributed code that allows the backend servers to publish messages into the backplane for consumption by the API/graphql servers. This means that ITopicSender is registered in DI, but ITopicReceiver is not. PostgresChannel is used by with sending and receiving code paths and executes listen on all code paths. Maybe PostgresChannel needs to be split or allow to be configured so it doesn't listen when in a "SendOnly" configuration as listening to events in a publish only scenario is pointless.

Steps to reproduce

I'm sorry but i dont have a repro yet, but thought i would open an issue to start a discussion in case this sparked an idea of the cause for @PascalSenn

Relevant log output

No response

Additional Context?

No response

Version

13.8

Start by tracing PostgresChannel through the ITopicSender and ITopicReceiver registrations in the subscriptions setup. Reproduce the send-only backend scenario described for version 13.8 and check whether publishing causes a PostgreSQL LISTEN task to start. Done means a sender-only process can publish without beginning the long-running listener.