Please answer the following questions for yourself before submitting an issue.
Subscribing to ** event should capture all events emitted or broadcast from services over NATS transport
** does not seem to catch anything
Events are not triggered for ** subscriptions when multiple services are dispatching events across NATS transportation
Please provide detailed steps for reproducing the issue.
const broker = new ServiceBroker({
logger: console,
transporter: "NATS"
});
broker.createService({
name: "test",
actions: {
emit(ctx) {
ctx.emit('this.is.an.event');
}
},
events: {
"**"(data, sender, eventName){
this.logger.info("event triggered", eventName)
}
}
});
https://github.com/levia7han/moleculer-wildcard
Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions.
Attempting to write a service that logs all events broadcast or emitted within the system. I noticed that although unit tests were working, when we tried to get integration tests and real life testing to work we were not seeing the events we expected in the logs.
After digging into the code it seems like there is an issue with moleculer using * as a wildcard character where NATS expects > as a wildcard.
I have a pull request that adds the > wildcard along with tests that seems to fix this issue. It is located at https://github.com/levia7han/moleculer/tree/nats-wildcard
I can't reproduce it. Your code snippet is working properly:
[2019-04-09T19:10:15.985Z] INFO bobcsi-pc-11044/BROKER: Moleculer v0.13.8 is starting...
[2019-04-09T19:10:15.988Z] INFO bobcsi-pc-11044/BROKER: Node ID: bobcsi-pc-11044
[2019-04-09T19:10:15.989Z] INFO bobcsi-pc-11044/BROKER: Namespace: <not defined>
[2019-04-09T19:10:15.990Z] INFO bobcsi-pc-11044/REGISTRY: Strategy: RoundRobinStrategy
[2019-04-09T19:10:15.993Z] INFO bobcsi-pc-11044/BROKER: Serializer: JSONSerializer
[2019-04-09T19:10:15.995Z] INFO bobcsi-pc-11044/BROKER: Transporter: NatsTransporter
[2019-04-09T19:10:15.996Z] INFO bobcsi-pc-11044/BROKER: Registered 10 internal middleware(s).
[2019-04-09T19:10:16.004Z] INFO bobcsi-pc-11044/TRANSIT: Connecting to the transporter...
[2019-04-09T19:10:16.360Z] INFO bobcsi-pc-11044/TRANSPORTER: NATS client is connected.
[2019-04-09T19:10:16.884Z] INFO bobcsi-pc-11044/REGISTRY: '$node' service is registered.
[2019-04-09T19:10:16.885Z] INFO bobcsi-pc-11044/REGISTRY: 'test' service is registered.
[2019-04-09T19:10:16.886Z] INFO bobcsi-pc-11044/TEST: event triggered $services.changed
[2019-04-09T19:10:16.886Z] INFO bobcsi-pc-11044/BROKER: ServiceBroker with 2 service(s) is started successfully.
[2019-04-09T19:10:16.888Z] INFO bobcsi-pc-11044/TEST: event triggered $broker.started
mol $ call test.emit
mol $ call test.emit
{ options: {}, actionName: 'test.emit' }
>> Call 'test.emit' with params: {}
[2019-04-09T19:10:46.978Z] INFO bobcsi-pc-11044/TEST: event triggered this.is.an.event
>> Execution time: 4ms
>> Response:
undefined
mol $
Sorry, that snippet was a bit misleading. Let me clarify.
This issue happens in integration tests and running live from docker-compose. I have not had any luck reproducing it in a unit test or running local. In fact it will pass all unit tests, which is where I was bitten.
If you check out the repository I linked to, you should see what is going on better. As I have integration tests and the docker-compose setup to repo the issue.
But if I was to create two services putting both into separate docker containers. One with an action that broadcasts an event. The other subscribed to all events ("**"). Then I was to call the first container. (through the repl for instance) I will not see the event fire in the other container.
If I subscribe to the event directly it will work. But the wildcards don't seem to. To further this strangeness; If I subscribe to "**" and "*.*.*.*"And fire off and event "this.is.an.event" I will get two events logged. But then if you remove the "*.*.*.*" event you get no event logged.
Are you using disableBalancer: true?
yes
Ok, the problem is because disableBalancer. So adding > to matcher function is not a good solution because > wildcard is only NATS specific. We need to handle wildcards handling in NATS transporter code.
I will fix it.
Sounds good, I was wondering if there was a better place for it than the match method.
Thank you very much for addressing this.
@icebob Thanks for fixing this for us. We were just wondering when you were planning your next release.
I've just released 0.13.9
You are the best. Thanks
Most helpful comment
Sounds good, I was wondering if there was a better place for it than the match method.
Thank you very much for addressing this.