Listener does not correctly handle optional & wildcard routes.

[SippieCup]

Runtime

node.js

Runtime version

20.14.0

Module version

14.0.0

Last module version without issue

No response

Used with

Hapi

Any other relevant information

when adding subscriptions to the listener, wildcard paths are not handled correctly in internals.Subscribers.prototype.add . This leads to internals.Listener.prototype._publish incorrectly determining which subscribers to send the message to, due to only checking for length, and not number of parameters as wildcard parameters appear in the paramsArray as a single string and must be manually split.

This means that you can't have a greedy listener, or optional params as they won't match when going backwards, since they originally have 0 parameters provided or has multiple parameters merged within the last value of match.paramArray

potential solution:

On seeing a wildcard route, the last value of the paramsArray should be split on / and flattened into the paramsArray.

What are you trying to achieve or the steps to reproduce?

I am trying to use a wildcard parameter to publish changes in real time from a broad view to then be filtered to more specific ones. similar to the REST spec.

An example:

model of products. there are two parameters:

    actions?: 'insert' | 'delete' | 'update'
    id?: number
}

the route would be /products/changes/{params*2} or just /products/changes/{params*}

this route should result in this table:

users	absolute path	desired result
1	/products/changes/	should get every message send back to the route
2	/product/changes/insert	should get every insert message
3	/products/changes/update	should get every update message
4	products/changes/update/5	should only get update messages for product id 5

if you attempt to use a wildcard for multiple parameters, or an optional parameter, on a route, it still needs to be published as the full path to match the more specific filters.

What was the result you got?

Only the fully defined path /products/changes/updates/5 gets the message, rather than every listener leading up to that point.

What result did you expect?

the lookup going backwards fails because it must be published to /products/changes/update/5 to support the other conditions, and thus, only user 4 gets the message. instead of user 1, 3 and 4 even though they all matched the route.