Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

duplicate output messages #6056

Closed
hjoliver opened this issue Apr 4, 2024 · 3 comments
Closed

duplicate output messages #6056

hjoliver opened this issue Apr 4, 2024 · 3 comments
Assignees
Labels
bug Something is wrong :( small
Milestone

Comments

@hjoliver
Copy link
Member

hjoliver commented Apr 4, 2024

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 ?

@hjoliver hjoliver added bug Something is wrong :( small labels Apr 4, 2024
@hjoliver hjoliver added this to the cylc-8.3.0 milestone Apr 4, 2024
@oliver-sanders
Copy link
Member

oliver-sanders commented Apr 5, 2024

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
Copy link
Member Author

hjoliver commented Apr 8, 2024

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

@hjoliver hjoliver modified the milestones: cylc-8.3.0, cylc-8.x Apr 8, 2024
@oliver-sanders oliver-sanders self-assigned this Jul 15, 2024
@oliver-sanders oliver-sanders modified the milestones: 8.x, 8.3.3 Jul 15, 2024
@oliver-sanders
Copy link
Member

oliver-sanders commented Jul 15, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is wrong :( small
Projects
None yet
Development

No branches or pull requests

2 participants