Closing as pre-dates the new decision making process and has not progressed

Thank you for responding.

I think there is some misunderstanding here.

There is every chance I have misunderstood the current behaviour or the intent.

Currently, there is a bug, that prevents publisher registration if there are no subscribers registered yet. And FoliJet team has created a Jira issue for that. So the possibility to register a publisher should not depend on subscribers' existence.

Oh, I was not aware of this issue. Please could you refer me to the JIRA so I can learn more about it.

Regarding the inability to send event if there are no subscribers for that it was a deliberate decision. The main goal is to do not waste resources that are required to store all those events that never will be delivered.

I can very much understand not wanting to waste storing messages that won't be delivered to any subscribers. (One trade-off with that is a reduction in the ability to diagnose issues that might occur)

What I am yet to understand is why this decision needed to be public, in the sense that the client is informed, rather than private within mod-pubsub.

By making it public, either the publisher has to know that subscribers are present (which increases coupling between them) and otherwise refrain from publishing, or it needs to apply special case logic to ignore this error (which is brittle and might hide genuine errors).

Does that make sense? Please can you help me understand the intent behind making this decision public to the client?

I think there is some misunderstanding here.
Currently, there is a bug, that prevents publisher registration if there are no subscribers registered yet. And FoliJet team has created a Jira issue for that.
So the possibility to register a publisher should not depend on subscribers' existence.

Regarding the inability to send event if there are no subscribers for that it was a deliberate decision. The main goal is to do not waste resources that are required to store all those events that never will be delivered.

Personal thoughts

My understanding of the intent behind the publish-subscribe pattern is to decouple publishers and subscribers. I think an implicit part of that is that there should not need to be any subscribers for a message to be successfully published (to no one, if transitive).

publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorize published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are.

from Wikipedia (emphasis my own)

Externally failing publishing of a message if there are no subscribers creates an implicit coupling between the publisher and at least one subscriber, because the subscriber must be present for the publisher to function as intended.

To me, it is counter intuitive that a message has to be subscribed to before it can be published. I understand why it's desirable for subscribers to be present before any messages are published, so that no messages are missed. However, this decision means that no publisher can be enabled for a tenant, without knowing a subscriber is present, unless these errors are acceptable.

The workaround, to ignore this particular failure, is brittle and increases the coupling between the publisher and mod-pubsub and introduces the possibility that genuine failures are missed or ignored.