Answer by Reguel Wermelinger

Reguel Wermelinger — Wed, 15 May 2019 09:44:43 -0400

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.

Answers to: Signal wildcards behave in an unexpected way

Answer by Reguel Wermelinger