nats-server is complaining about overlapping jetstream api subjects on stream creation when not valid [v2.11.2]

[AresAutomata]

Observed behavior

In nats-server version 2.11.2, it appears that creating a stream using mostly wildcards in the subjects field raises an error saying: nats: error: could not create Stream: subjects overlap with an existing stream (10065).

I've observed that if the first 2 tokens are wildcards. the stream creation will always fail.

Here is a screenshot of using the cli to replicate the issue.

This is a valid stream being created with the same pattern.

Expected behavior

A valid stream for subjects with wildcards appearing for the first 3+ tokens is created.

This should be valid.

Server and client version

nats-server version = 2.11.2
nats cli version = 0.1.5

Host environment

No response

Steps to reproduce

Outlined in the screenshots above

[neilalexander]

Are you overlapping with the interest of other configured streams? Streams have to have non-overlapping interest within a given account.

[AresAutomata]

You are probably overlapping with $JS.API and other system subjects, which is prohibited intentionally.

We have intentionally hardcoded one of the tokens in the subject: i.e. *.*.*.*.*.*.*.broadcast.*. Should this not separate subject from jetstream specific subjects?

This is occurring when trying to create a the first stream in a very simple environment.

[neilalexander]

Does nats stream ls -a definitely report no other streams in this case?

[AresAutomata]

Does nats stream ls -a definitely report no other streams in this case?

Yep no streams are reported. We bypassed this issue by adding a constant prefix to the subject.

[neilalexander]

With server v2.11.2 and CLI v0.1.5, I fail to create the streams as you do, but the error returned is because of the JS API collision, not a duplicate stream.

For your first example:

nats stream create test --subjects="*.*.*.*.test.*.*" --defaults
nats: error: could not create Stream: subjects that overlap with jetstream api require no-ack to be true (10052)

For your second example:

nats stream create test --subjects="*.test.*.*.*.*" --defaults
nats: error: could not create Stream: subjects that overlap with jetstream api require no-ack to be true (10052)

... which makes sense because the first wildcard could match $JS and therefore it collides with one of the reserved namespaces.

What isn't clear is why you are getting subjects overlap with an existing stream if there are really no streams (which would include KV and object store buckets). Is this a clustered setup or a standalone server?

[fmontorsi-equinix]

Also happens to me with 2.11.3 with a stream having subjects like:

• *.enroll
• *.heartbeat

I fixed that by adding a prefix to all these subjects like:

• xyz.*.enroll
• xyz.*.heartbeat

[simonfxr]

This new restriction creates a significant problem for our complex NATS deployment. We use a convention where the first few segments identify the sender, primarily to enable fine-grained access control and easier observability. Most of our stream topics follow the structure *.*.*.*.non.wildcard.segments, and the newly introduced stream subject restriction discussed here disrupts our deployment. Is there any way to make this restriction less stringent?