Signal wildcards behave in an unexpected way

Hi Axon.ivy Team,

I'm using Axon.ivy LTS 7.0.8 and I'm getting an issue related to Signal.

I have 4 signal receivers:

one
one:two
one:two:three
one:two:three:four

When I send the signal one:two:three:four, I expect that only the (4) receiver would be triggered. Unfortunately, I was surprised that all four of them were triggered.

all four signal receivers are triggered

According to the official document, I would expect that only if I use the wildcard in the pattern of the Receiver, I will have the same behaviours (one:*, one:two:*, one:two:three:*) but in this case, the wildcard does not matter much here.

Is it a bug or by design that the Signal Receivers behave like that?

Thanks! Jack

signals

asked 14.05.2019 at 10:30

vagabond
(suspended)
accept rate: 50%

edited 15.05.2019 at 09:45

Reguel Werme... ♦♦
9.4k●3●19●58

One Answer:

active answers oldest newest most voted

Hi Jack

that the signals are fired here is expected. Signal codes are hierarchical and can be used pretty much like package names in java. the idea is that one fires acme:cool:wf:customer:signed:up:3424 and starts can listen to this signals by using a parent code: e.g. acme, acme:cool, acme:cool:wf, acme:cool:wf:customer, acme:cool:wf:customer:signed, acme:cool:wf:customer:signed:up the wildcard at the end is not necessary. But it is required if a listener should react to wildcards on the left side of the code: *:cool:wf:customer is a valid example of a wildcard.

But I see 2 problems exposed by your question:

signal wildcards are currently documented in a misleading way in the designer guide. So I'll try to clarify this chapter.
and we allow to inscribe patterns such as acme:* but at runtime these starts are not fired. That's a bug in my opinion. Not important as you can easily skip the wildcard and have the result you'd expect. But I'll address it in XIVY-3220.

link

answered 15.05.2019 at 09:44

Reguel Werme... ♦♦
9.4k●3●19●58
accept rate: 70%

Hi Reguel Wermelinger, in my opinion, if I define a signal receiver to listen to only:this, then only a SignalCode of only:this can trigger it. If I want the current behavior, I'd define only:this:*. To me, this is more intuitive.

(16.05.2019 at 10:58) vagabond

Your suggestion is what we had for several sprint in place and was actually our first approach. Based on the feedback we got back then we switched to prefix matching without the explicit wildcard to ease listener definitions (users got annoyed by the repetitive asterics definition work). However, now we can't easily change that behaviour without braking existing workflows. But I guess that in most cases you can easily work around that behaviour if you dont like it.

(17.05.2019 at 08:37) Reguel Werme... ♦♦

Your answer

toggle preview

community wiki:

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

*italic* or _italic_
**bold** or __bold__
link:[text](http://url.com/ "Title")
image?![alt text](/path/img.jpg "Title")
numbered list: 1. Foo 2. Bar
to add a line break simply add two spaces to where you would like the new line to be.
basic HTML tags are also supported

learn more about Markdown

Tags:

signals ×9

Asked: 14.05.2019 at 10:30

Seen: 1,183 times

Last updated: 17.05.2019 at 08:38

Signal wildcards behave in an unexpected way

Follow this question

Related questions