duplicate output messages

[hjoliver]

While testing #6046 I noticed we can assign the same output message to different triggers:

[scheduling]
  [[graph]]
      R1 = "foo:x? & foo:y? => bar"
[runtime]
  [[bar]]
  [[foo]]
     script = "cylc message 'shake n bake'"
     [[[outputs]]]
          x = "shake n bake"
          y = "shake n bake"

This ⏫ does the right thing and completes both outputs, but I'm pretty sure it would be a mistake if found in the wild.

You might want to add the fix into #6046 @oliver-sanders ?

[oliver-sanders]

We could catch your retro example, but the general solution gets tricky because the message side of the mapping can accept patterns e.g:

[runtime]
  [[task]]
    [[[outputs]]]
      x = foo .*
      y = .* bar

Beyond exhaustively checking whether there is some message that could satisfy both it would be hard to defend against this.

Although it wasn't the intended usage, it could kinda be argued that it's valid for a single message to map onto multiple outputs e.g something like:

script = """
    cylc message -- data x, y, z written
"""
[[[outputs]]]
  x = data .*x.*  written
  y = data .*y.*  written
  z = data .*z.*  written

Surprisingly, there don't presently appear to be any uses of custom outputs at our site, so no pre-existing use cases to constrain us. Could go either way.

[hjoliver]

the message side of the mapping can accept patterns e.g:

That's news to me, which had me doubting my sanity, but from a quick look it doesn't seem to be true

It's a good idea though. I like your x, y, z example. But probably not useful without pattern matching?

Suggest:

• if we want to implement output message pattern matching, put up a new Issue for that, and close this
• otherwise implement a quick duplication check to close this issue

[oliver-sanders]

the message side of the mapping can accept patterns e.g:

That's news to me, which had me doubting my sanity, but from a quick look it doesn't seem to be true

I'm not sure where I got that impression from, I thought this was something we had!

In no rush to go about implementing message patterns, however, I expect they could be useful for cylc broadcast type use cases, e.g. reporting a file path.