Leaf node interest propagation filtering with queue groups - Exact subject not matching

[roeschter]

Observed behavior

• A leaf node is connected to a hub through a user with restrictive permissions.
• In this example case publish allow "services.device.remote-lock"
• A services is listening on the leaf "services.device.remote-lock" with queue group
• A client is trying access the service from the hub publishing to "services.device.remote-lock"
• The message is not received by the leaf

Null tests and context:

• Setup works when the user permissions have a wildcard in the last element - e.g "services.device.*" - "services.device.>"
• Setup works when the service connects to the hub with the same user as the leaf node (the leaf node interest propagation is the crux, not the security checks themselves)
• Setup works when no queue group is used
• Tracing interest propagation shows that the subject interest is not propagated to the hub

Expected behavior

Subscription interest propagates even if subject allow filter matches the subject exactly.

Suspected reason: This could be a regression in 2.10.23 due to recent fixes to leaf node interest propagation with queue groups

Server and client version

2.10.23
Nats CLI - main branch

Host environment

Windows

Steps to reproduce

Defect case

1. Start leaf and hub with the configuration files included here
2. nats --server=nats://127.0.0.1:4223 reply services.device.remote-lock OK
3. nats request --server=nats://127.0.0.1:4222 services.device.remote-lock Hello

Nulltest-1
2. nats --server=nats://127.0.0.1:4223 sub services.device.remote-lock
3. nats --server=nats://127.0.0.1:4222 pub services.device.remote-lock Hello

Nulltest-2
2. nats --server=nats://127.0.0.1:4222 --user=user2 --password=user2 reply services.device.remote-lock OK
3. nats --server=nats://127.0.0.1:4222 request services.device.remote-lock Hello

20241219_Leafnode_interest_graph_issue.zip