commands: traceback when specifying jobs

[wxtim]

Scheduler log traceback appears when jobs are provided as task arguments, e.g:

cylc release workflow//<cycle>/<task>/01

OP:

Running against any old workflow:

cylc <workflow>//2397/bar/NN/ (got by pressing tab and letting the autocomplete go to it).

Gives the command queued output in the dispatching terminal, but the following in the log:

2024-06-06T16:03:50+01:00 INFO - Command "set" received. ID=89921d9f-9447-4cb4-acce-5fc9f972076e
    set(flow=['all'], flow_wait=False, outputs=[], prerequisites=[], tasks=['2397/bar/NN'])
2024-06-06T16:03:50+01:00 ERROR - Traceback (most recent call last):
      File "/net/home/h02/tpilling/metomi/cylc-flow/cylc/flow/scheduler.py", line 948, in process_command_queue
        n_warnings = await cmd.__anext__()
      File "/net/home/h02/tpilling/metomi/cylc-flow/cylc/flow/commands.py", line 155, in set_prereqs_and_outputs
        yield schd.pool.set_prereqs_and_outputs(
      File "/net/home/h02/tpilling/metomi/cylc-flow/cylc/flow/task_pool.py", line 1887, in set_prereqs_and_outputs
        itasks, future_tasks, unmatched = self.filter_task_proxies(
      File "/net/home/h02/tpilling/metomi/cylc-flow/cylc/flow/task_pool.py", line 2285, in filter_task_proxies
        matched, unmatched = filter_ids(
      File "/net/home/h02/tpilling/metomi/cylc-flow/cylc/flow/id_match.py", line 207, in filter_ids
        raise NotImplementedError
    NotImplementedError
    
2024-06-06T16:03:50+01:00 ERROR - Command "set" failed. ID=89921d9f-9447-4cb4-acce-5fc9f972076e

Originally posted by @wxtim in #6112 (comment)

Similarly

cylc hold --after 239413 <workflow> is accepted but later causes traceback.

[oliver-sanders]

Note, this is longstanding (not introduced in 8.3.0) and not yet reported so not a release blocker.

[wxtim]

Note, this is longstanding (not introduced in 8.3.0) and not yet reported so not a release blocker.

Esp since the traceback doesn't take the scheduler down!

[oliver-sanders]

Suggest tokenising IDs at queue time, then filtering them according to the accepted type(s) for the command.

E.G. something along the lines of this:

diff --git a/cylc/flow/commands.py b/cylc/flow/commands.py
index 28de0d16e..37c99367f 100644
--- a/cylc/flow/commands.py
+++ b/cylc/flow/commands.py
@@ -71,9 +71,11 @@ from cylc.flow.exceptions import (
     CommandFailedError,
     CyclingError,
     CylcConfigError,
+    InputError,
 )
 import cylc.flow.flags
 from cylc.flow.log_level import log_level_to_verbosity
+from cylc.flow.id import tokenise_ids
 from cylc.flow.network.schema import WorkflowStopMode
 from cylc.flow.parsec.exceptions import ParsecError
 from cylc.flow.task_id import TaskID
@@ -214,8 +216,14 @@ async def stop(
 @_command('release')
 async def release(schd: 'Scheduler', tasks: Iterable[str]):
     """Release held tasks."""
+    tokens_list, bad_ids = tokenise_ids(*tasks)
+    if bad_ids:
+        raise InputError(
+            'Invalid IDs provided:'
+            '\n*'.join(f'{id_} - {reason}' for id_, reason in bad_ids)
+        )
     yield
-    yield schd.pool.release_held_tasks(tasks)
+    yield schd.pool.release_held_tasks(tokens_list)
 
 
 @_command('release_hold_point')
diff --git a/cylc/flow/id.py b/cylc/flow/id.py
index cba3c4833..83f2a3d3e 100644
--- a/cylc/flow/id.py
+++ b/cylc/flow/id.py
@@ -888,3 +888,23 @@ def contains_multiple_workflows(tokens_list: List[Tokens]) -> bool:
         (tokens['user'], tokens['workflow'])
         for tokens in tokens_list
     }) > 1
+
+
+def tokenise_ids(
+    *ids: str, cylc_type=IDTokens.Task
+) -> Tuple[List[Tokens], List[Tuple[str, str]]]:
+    good = []
+    bad = []
+    for id_ in ids:
+        tokens = Tokens(id_)
+        if tokens.lowest_token == cylc_type:
+            good.append(tokens)
+        else:
+            bad.append(
+                (
+                    id_,
+                    f'Expected "{cylc_type.value}"'
+                    'got "{tokens.lowest_token.value}"',
+                )
+            )
+    return good, bad

However, this will require some bodging in the TaskPool as the ID filtering (which happens at command run-time) is based on string IDs not Tokens yet.

Until then, we can just make the message nicer (but it won't get reported back to the user, only written in the log).