Consumers in different domains interfere with each others

[cuberri]

Observed behavior

Consumers in different js domains interfere with each others when their name and stream names are the same.

Expected behavior

Using domains should allow to create independent namespaces, as the documentation states.

Server and client version

natscli 0.01.6
nats-server 2.10.25

Host environment

No response

Steps to reproduce

• Spin up 2 nats instances and configure them as a hub-spoke topology with a leaf node connection, within 2 different domains hub and spoke
• In the hub instance, create a stream str and a consumer cons that consumes messages from str
• In the spoke instance, create a stream str mirroring the one in the hub and a consumer cons associated to it
• In the hub instance, publish x messages in a subject that is captured by stream str. The consumer cons in the hub has now x unprocessed messages
• In the spoke instance, use the consumer cons to pull all the messages from the mirrored stream
• Now, both consumers in hub and spoke have 0 unprocessed messages even though the consumer in the hub hasn't been used yet. Thus, the consumer in spoke managed to wipe all the messages (i.e. transfer its state) available from the one in hub

Just like this issue #6431 regarding FC.>, this is most likely due to the fact that JSC.> is not prefixed/differentiated per domain.

However, the documentation mentions:

Please be aware that each domain is an independent name space. Meaning, inside the same account it is legal to use the same stream name in different domains

This is more than a small caveat, as in, a consumer state in a domain has a direct impact on a consumer in another one, leading to applications not being able to pull messages from a consumer they've subscribed to.

Of course, a workaround could be to name the consumers differently. But then this defeats the purpose of using domains to create "independent name spaces". This specifically means that all the domains need to be aware of each other's consumer and/or stream names and not use the same ones so that they don't interfere with each other. This becomes even more risky in the context of mirrored streams, where users are likely tempted (not forced of course) to use the same stream name for a mirror.