Always keep failed tasks visible?

[jonnyhtw]

hi there,

i want to be able to debug failed tasks in my workflow but they disappear when they are more than one graph-view-arrow away from a running task.

consider this graph view (which has hidden failed tasks in it)…

if i now set the graph extent to 5 and trigger a trivial earlier task i get this…

and this shows the rose_ana tasks that i want to debug. this view however only applies to the graph view but i want to view the ‘table’ view also.

is there a way to get cylc to always ‘keep’ failed tasks in view?

thanks!

[hilary.j.oliver]

[Edited to reduce verbosity!].

How much you see of the graph around “active” tasks is merely a visualization choice. Expanding the graph window extent affects all UI views equally, not just the graph view. The table and tree views should show the same tasks that you see in the graph view.

Your “disappearing” task must be complete despite the failure - i.e. the graph says its success was not required. Completed tasks, whether succeeded or failed, will not stall the workflow and will drop out of the active window as the workflow moves on.

If you don’t mark the task’s success as optional, it will be retained in the active window as an incomplete task, until you deal with it.

[jonnyhtw]

thanks hilary!

appreciate the reply, i did look into this (local chat, online docs, previous discourse questions) and am still confused.

consider this graph fragment…

… which comes from this code fragment…

{% if TEST_NOSTASH %}
         R1  = """
                    atmos_main[^]:submit => atmos_nostash
                    atmos_main[^] & atmos_nostash => rose_ana_nostash?
                    rose_ana_nostash? => housekeeping
                    """
{% endif %}

in the cylc 7 version of this workflow this is was the code…

{% if TEST_NOSTASH %}
        [[[ R1 ]]]
            graph = """
                    atmos_main[^]:submit => atmos_nostash
                    atmos_main[^] & atmos_nostash => rose_ana_nostash <--- different
                    rose_ana_nostash:finish => housekeeping <--- different
                    """
{% endif %}

… which is not allowed in cylc 8.

the code is working to the extent that housekeeping is not being triggered because of previous failed tasks but how would i change this code to force the failed rose_ana_nostash task to remain visible until it is fixed?

thanks

[hilary.j.oliver]

The key is the ? here:

@jonnyhtw

rose_ana_nostash?

That is short for rose_ana_nostash:succeed?, i.e. success is optional for this task. In other words you expect it to fail sometimes and the graph handles that. In you case, the graph says this:

 rose_ana_nostash:finish => housekeeping

:finish means :succeed? OR :fail?, so the graph does handle the failure of this task. It is not a critical failure such as when a success-required task fails. Those get retained as incomplete in the active window - and always visible - until dealt with, because the graph does not say what to do in that case.

The goal should not be to make an optional-success task “remain visible”, if its success really is optional. Just expand the visualization window so you can still see it if you need to after the workflow moves on.

Hope that makes sense!

[jonnyhtw]

thanks hilary!

rose_ana_nostash? …is short for rose_ana_nostash:succeed?

i got this wrong! i thought this mean ‘only do what follows if it succeeded and stall if it fails’!

i think what i was after in my initial question was…

… a critical failure such as when a success-required task fails. Those get retained as incomplete in the active window - and always visible - until dealt with…

to get this i’d do this i think?..

{% if TEST_NOSTASH %}
         R1  = """
                    atmos_main[^]:submit => atmos_nostash
                    atmos_main[^] & atmos_nostash => rose_ana_nostash:succeeded
                    rose_ana_nostash:succeeded => housekeeping
                    """
{% endif %}

The goal should not be to make an optional-success task “remain visible”, if its success really is optional. Just expand the visualization window so you can still see it if you need to after the workflow moves on.

ok yeah i see that now! in the type of model development that i do, i can see how rose_ana tasks could be considered optional or success-required depending on the application.

i guess the runahead limit would stop the workflow from advancing too far anyway…

thanks again,

jonny

[jonnyhtw]

just to confirm that this…

{% if TEST_NOSTASH %}
         R1  = """
                    atmos_main[^]:submit => atmos_nostash
                    atmos_main[^] & atmos_nostash => rose_ana_nostash:succeeded
                    rose_ana_nostash:succeeded => housekeeping
                    """
{% endif %}

… does produce what i wanted (although in this case i bodged the workflow to make the rose_ana tasks fail…) and the atmos_main task is ‘waiting (runahead)’ which is also what i expected!

thanks for your help,

jonny