@hjoliver Can you provide a quick suite.rc snippet to repeat?

(This was reported by Xiao at BoM).

This should work, but fails validation:

# many local tasks (<p>) all depend on the same remote task:
graph = foo<p><other::bar> => baz

But Xiao's example was more like this:

graph = foo<p><other::bar<p>> => baz

This should have the same effect as:

foo_p1<other::bar_p1> => baz
foo_p2<other::bar_p2> => baz
...

Maybe there's a use case for that. However this assumes the same parameter range and template in both suites. Use of two parameters would expand all-to-all (like foo<a> => bar<b> does) which I doubt would be what's wanted... but I suppose we could fail this unless the same parameter set is used with both the local and remote task name...

(assuming I remember correctly how the substitution in of the remote task works)

It's worth noting that this

# many local tasks (<p>) all depend on the same remote task:
graph = foo<p><other::bar> => baz

Is bad, as multiple polling tasks all polling the same remote is redundant, extra task proxies, dependencies etc. Better to have:

graph = foo<other::bar> => foo<p> => baz

so only one remote polling operation takes place for the one thing that is of interest.

@arjclark - that's a very good point. I'll inquire of Xiao as to her use case...

You mention in this bit:

But Xiao's example was more like this:

graph = foo<p><other::bar<p>> => baz

I suspect Xiao may have something along lines of:

graph = poll_memberN<other :: remote_memberN> => process_all_members

Which is less redundant but its better to have a dummy task in the remote suite to represent the whole family of things being finished. (though linearisation now being recorded in the suite db should hopefully mean we can poll family statuses via the cylc suite-state command in future)