With spawn-on-demand there are often no waiting tasks in the pool, which makes "hold" (by glob to match in the pool) pretty
much useless. Holding a task that is already running has no effect (except to hold back any retries).

...
a => b => FAM  # b is currently running
...

If b is running and I want to pause execution of this branch without pausing the whole workflow, I currently have to individually hold all members of FAM (family names and globs currently only match in the task pool).

Making hold work the way that users no doubt expect - i.e., to be able to easily hold parts of a running workflow without pausing the whole thing - should IMO be part of our current push to get intervention capability nailed down in Cylc 8.

Option A

Held running tasks should pass the held "attribute" on to children.

If I hold b, members of FAM will be spawned when b succeeds, but they will be held.

Pros:

• easy to implement

Cons:

• we end up with held tasks that I didn't explicitly ask to hold
• they get held some time after I issued the hold command
  • (BUT we already have that for future hold by explicit task ID)

Option B

Held running tasks should not spawn children until released.

If I hold b, it will remain in the pool as succeed and held, until released, at which point it will spawn FAM.

Pros:

• more direct and more intuitive (the only tasks that get held are those I explicitly ask for)

Cons:

• delayed spawning is more difficult to implement and requires DB support.
  • (BUT we already have that for the --wait flow trigger option)

I think I prefer Option B. It is more intuitive and has one less "con" by my count.