# Task wrangling issues

**URL:** <https://cylc.discourse.group/t/task-wrangling-issues/517>\
**Category:** Cylc 8 Migration\
**Created:** [August 11, 2022, 6:06am UTC](https://cylc.discourse.group/t/task-wrangling-issues/517 "2022-08-11T06:06:20Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![srennie](https://avatars.discourse-cdn.com/v4/letter/s/8edcca/32.png) [@srennie](https://cylc.discourse.group/u/srennie)\
**Post date:** [August 11, 2022, 6:06am UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/1 "2022-08-11T06:06:20Z")

</div>

Hi.  
I’m trying to create a new cylc8 suite based on my cylc7 NWP suite (nothing as simple as helloworld because I’m not that sensible).

My first task kept failing because it took me a while to get all the correct environment variables defined in the task. However, my workflow changes were not being updated in the job script. My work pattern was to modify my sources, run cylc reinstall, cylc reload (and repeat a couple times just in case), then cylc trigger … the task. The new variables defined in the workflow did not appear in the jobscript, even though they did appear in the workflow definition with the output of cylc config.  
Why doesn’t reinstalling and reloading reliably update the job script with new changes? (A colleague reported a similar issue).

My second task was failing because it couldn’t find cylc. (Don’t ask me why my first task didn’t have this issue…) I eventually worked out it is because I had the cylc path in global.cylc pointing to someone else’s home directory, and fixed this. However, because the job didn’t get far enough, cylc doesn’t realise it failed. cylc poll returns a submit-failed state.  
I did manage to retrigger the task once after a cylc poll, because it changed the state back to waiting, however I still hadn’t fixed the cylc path then. However, thereafter, I was not able to resubmit the task because it remained in the submitted state even when it polls as submit-failed. How do I get the task back to a state where I can submit it again?

Log outputs

> 2022-08-11T05:51:52Z INFO - [command] poll\_tasks  
> 2022-08-11T05:51:52Z INFO - Processing 1 queued command(s)  
> 2022-08-11T05:51:52Z INFO - Command succeeded: poll\_tasks([‘20220321T0600Z/fcm\_make\_um’])  
> 2022-08-11T05:51:53Z INFO - [20220321T0600Z/fcm\_make\_um submit-failed job:03 flows:1] (polled)submission failed at 2022-08-11T05:15:28Z  
> 2022-08-11T05:51:53Z CRITICAL - [20220321T0600Z/fcm\_make\_um submit-failed job:03 flows:1] submission failed  
> 2022-08-11T06:00:31Z INFO - [20220321T0600Z/fcm\_make\_um submitted job:03 flows:1] poll now, (next in PT15M (after 2022-08-11T06:15:31Z))  
> 2022-08-11T06:00:33Z INFO - [20220321T0600Z/fcm\_make\_um submit-failed job:03 flows:1] (polled)submission failed at 2022-08-11T05:15:28Z  
> 2022-08-11T06:00:33Z CRITICAL - [20220321T0600Z/fcm\_make\_um submit-failed job:03 flows:1] submission failed  
> 2022-08-11T06:01:19Z INFO - [command] poll\_tasks  
> 2022-08-11T06:01:19Z INFO - Processing 1 queued command(s)  
> 2022-08-11T06:01:19Z INFO - Command succeeded: poll\_tasks([‘20220321T0600Z/fcm\_make\_um’])  
> 2022-08-11T06:01:20Z INFO - [20220321T0600Z/fcm\_make\_um submit-failed job:03 flows:1] (polled)submission failed at 2022-08-11T05:15:28Z  
> 2022-08-11T06:01:20Z CRITICAL - [20220321T0600Z/fcm\_make\_um submit-failed job:03 flows:1] submission failed  
> 2022-08-11T06:03:22Z INFO - Processing 1 queued command(s)  
> 2022-08-11T06:03:22Z WARNING - [20220321T0600Z/fcm\_make\_um submitted job:03 flows:1] ignoring trigger - already active  
> 2022-08-11T06:03:22Z INFO - Command succeeded: force\_trigger\_tasks([‘20220321T0600Z/fcm\_make\_um’], flow=[‘all’], flow\_wait=False, flow\_descr=None)

I can’t find a command reference in the documentation? I am working off the command line, no gui, and limited use of tui to check what is happening.

---

<div class="post-metadata">

**Author:** ![srennie](https://avatars.discourse-cdn.com/v4/letter/s/8edcca/32.png) [@srennie](https://cylc.discourse.group/u/srennie)\
**Post date:** [August 11, 2022, 6:47am UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/2 "2022-08-11T06:47:25Z")

</div>

I ended up killing the suite. I couldn’t use cylc stop because the task was “submitted”. cylc stop --kill got stuck in an endless loop of failing to kill the “submitted” task that had actualy failed. cylc stop --now --now stopped the suite. But then I couldn’t cylc play to restart it because the task I removed from the graph hadn’t been manually removed from the workflow. So I did a cylc clean and started over.

Now I’ve fixed the problem with the path to cylc, and my fcm\_make\_um task is failing, so I’m back to the problem of my changes to the configuration not being propagated into the job script after multiple reinstall and reloads.

BTW using version 8.0rc3 which is not the latest.

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [August 11, 2022, 9:13pm UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/4 "2022-08-11T21:13:38Z")

</div>

[previous unhelpful reply deleted/hidden]

The reload-related bug in 8.0rc3 only affected the preparing state, and in fact I can’t seem to replicate your reload problem here with rc3.

Can you try it with the following minimal example:

```ini
[scheduling]
    [[graph]]
        R1 = "a"
[runtime]
    [[a]]
        script = "echo X is $X; false"
        [[[environment]]]
            X = x

```

The one task, `a` will fail every time it runs, so you can reinstall → reload → retrigger at will after changing the value of `X` in the config file.

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [August 11, 2022, 9:33pm UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/5 "2022-08-11T21:33:30Z")

</div>

> [@srennie](#):
>
> I can’t find a command reference in the documentation?

Yes, we removed that. It’s not really “standard practice” to put command help listings in a user guide. If you find it helpful you can generate the whole lot yourself like this:

```bash
for COMMAND in $(cylc help all | awk '{print $1}'); do
   cylc $COMMAND --help
done > cylc-help.txt 

```

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [August 11, 2022, 9:39pm UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/6 "2022-08-11T21:39:03Z")

</div>

> [@srennie](#):
>
> I couldn’t use cylc stop because the task was “submitted”.

The `cylc stop` default is to wait for active tasks to complete before shut down, but `cylc stop --now` overrides that.

I’ll come back to your other issues in a while (gotta go for now)…

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [August 11, 2022, 9:43pm UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/7 "2022-08-11T21:43:28Z")

</div>

> [@srennie](#):
>
> (nothing as simple as helloworld because I’m not that sensible).

Posting a minimal example (such as mine just above) makes it easier for us to understand and replicate your problems!

Other system details may be important too, for issues involving (in)correct tracking of job status, such as: is your job platform remote, does it see the same filesystem as the scheduler host, what is the job runner (PBS, Slurm, …?), what’s the task communications method (TCP, polling, or ssh)?

---

<div class="post-metadata">

**Author:** ![srennie](https://avatars.discourse-cdn.com/v4/letter/s/8edcca/32.png) [@srennie](https://cylc.discourse.group/u/srennie)\
**Post date:** [August 12, 2022, 3:58am UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/8 "2022-08-12T03:58:41Z")

</div>

Minimal examples are good for diagnosing issues, but I never found them much use as a learning tool.

I’m running on the HPC, so no remote system, either running in background or submitting via PBS. Not sure about task communication. I can probably find out.

I have determined that I can reinstall and reload to my heart’s content, but I won’t notice that it didn’t work because there is a syntax error, unless I run cylc validate, or check the workflow log, to find there is a syntax error. Is reinstall and reload (and cylc config) supposed to also validate, or do I need to do this myself every time before I reinstall? cylc config appears to show the new changes even when my submitted job did not, so I suppose it doesn’t care if it’s valid?  
So that is probably the cause of some of my woes. I have been looking at my log files though, and I did a lot of reloading that did not appear to have an error associated with it. So I am not sure that 100% of the issues are due to syntax errors.

---

<div class="post-metadata">

**Author:** ![srennie](https://avatars.discourse-cdn.com/v4/letter/s/8edcca/32.png) [@srennie](https://cylc.discourse.group/u/srennie)\
**Post date:** [August 12, 2022, 4:06am UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/9 "2022-08-12T04:06:43Z")

</div>

I can reproduce the issue of being unable to restart a workflow with a task removed.  
e.g. Add R1 = “b” to the graph, and define it the same as “a”. Let it fail. then delete it from the graph, (validate), reinstall and reload. “b” is still there (e.g. in tui) because cylc doesn’t automatically remove tasks (I read that in the docs!). So I cylc stop. Then I cylc play again. The workflow fails to restart.

> (productive) gadi-login-04:dp9 run1 $ cylc stop hiworld  
> Done  
> (productive) gadi-login-04:dp9 run1 $ cylc play hiworld  
> …  
> 2022-08-12T04:02:43Z INFO - Extracting job.sh to /home/548/sjr548/cylc-run/hiworld/run1/.service/etc/job.sh  
> 2022-08-12T04:02:43Z INFO - Workflow: hiworld/run1  
> 2022-08-12T04:02:43Z INFO - LOADING workflow parameters  
> 2022-08-12T04:02:43Z INFO - + workflow UUID = 11d32f74-c6cc-4598-be5a-ebbf2d5c4133  
> 2022-08-12T04:02:43Z INFO - + UTC mode = False  
> 2022-08-12T04:02:43Z INFO - + cycle point time zone = Z  
> 2022-08-12T04:02:44Z INFO - LOADING task proxies  
> 2022-08-12T04:02:44Z INFO - + 1/a failed  
> 2022-08-12T04:02:44Z INFO - + 1/b failed  
> 2022-08-12T04:02:44Z ERROR - ‘~sjr548/hiworld/run1//$namespace|b’  
> Traceback (most recent call last):  
> File “/home/548/jt4085/.conda/envs/productive/lib/python3.9/site-packages/cylc/flow/data\_store\_mgr.py”, line 818, in generate\_ghost\_task  
> task\_def = self.data[self.workflow\_id][TASKS][t\_id]  
> KeyError: ‘~sjr548/hiworld/run1//$namespace|b’  
> During handling of the above exception, another exception occurred:  
> Traceback (most recent call last):  
> File “/home/548/jt4085/.conda/envs/productive/lib/python3.9/site-packages/cylc/flow/scheduler.py”, line 661, in start  
> await self.configure()  
> File “/home/548/jt4085/.conda/envs/productive/lib/python3.9/site-packages/cylc/flow/scheduler.py”, line 489, in configure  
> self.\_load\_pool\_from\_db()  
> File “/home/548/jt4085/.conda/envs/productive/lib/python3.9/site-packages/cylc/flow/scheduler.py”, line 732, in \_load\_pool\_from\_db  
> self.workflow\_db\_mgr.pri\_dao.select\_task\_pool\_for\_restart(  
> File “/home/548/jt4085/.conda/envs/productive/lib/python3.9/site-packages/cylc/flow/rundb.py”, line 842, in select\_task\_pool\_for\_restart  
> callback(row\_idx, list(row))  
> File “/home/548/jt4085/.conda/envs/productive/lib/python3.9/site-packages/cylc/flow/task\_pool.py”, line 456, in load\_db\_task\_pool\_for\_restart  
> self.add\_to\_pool(itask, is\_new=False)  
> File “/home/548/jt4085/.conda/envs/productive/lib/python3.9/site-packages/cylc/flow/task\_pool.py”, line 199, in add\_to\_pool  
> self.create\_data\_store\_elements(itask)  
> File “/home/548/jt4085/.conda/envs/productive/lib/python3.9/site-packages/cylc/flow/task\_pool.py”, line 221, in create\_data\_store\_elements  
> self.data\_store\_mgr.increment\_graph\_window(itask)  
> File “/home/548/jt4085/.conda/envs/productive/lib/python3.9/site-packages/cylc/flow/data\_store\_mgr.py”, line 654, in increment\_graph\_window  
> is\_orphan = self.generate\_ghost\_task(s\_tokens.id, itask, is\_parent)  
> File “/home/548/jt4085/.conda/envs/productive/lib/python3.9/site-packages/cylc/flow/data\_store\_mgr.py”, line 820, in generate\_ghost\_task  
> task\_def = self.added[TASKS][t\_id]  
> KeyError: ‘~sjr548/hiworld/run1//$namespace|b’  
> 2022-08-12T04:02:44Z CRITICAL - Workflow shutting down - ‘~sjr548/hiworld/run1//$namespace|b’  
> 2022-08-12T04:02:44Z WARNING - Incomplete tasks:  
> \* 1/a did not complete required outputs: [‘succeeded’]  
> 2022-08-12T04:02:44Z CRITICAL - Workflow stalled

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [August 12, 2022, 4:48am UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/10 "2022-08-12T04:48:12Z")

</div>

> [@srennie](#):
>
> Minimal examples are good for diagnosing issues, but I never found them much use as a learning tool.

Fair enough, but personally I’d rather avoid the complexities of managing an enormous NWP workflow (or whatever it might be) when trying to figure how some detail of scheduling or job control with Cylc.

> [@srennie](#):
>
> I have determined that I can reinstall and reload to my heart’s content, but I won’t notice that it didn’t work because there is a syntax error, unless I run cylc validate, or check the workflow log, to find there is a syntax error.

Ah, that could do it. Have you actually confirmed that reinstall + reload has the desired effect in your environment if you didn’t introduce a syntax error?

> [@srennie](#):
>
> Is reinstall and reload (and cylc config) supposed to also validate, or do I need to do this myself every time before I reinstall?

No, the job of `cylc reinstall` is just to reinstall files from source to an existing run directory. You should validate again after making any change to the workflow configuration.

The `cylc reload` command tells the running scheduler to reload the (reinstalled) config file. The scheduler then, in effect, validates the file, because it won’t parse correctly with a syntax error. However, you will have to look at the scheduler log to see those errors, so it’s much better to validate first.

> [@srennie](#):
>
> cylc config appears to show the new changes even when my submitted job did not, so I suppose it doesn’t care if it’s valid?

That should not be the case. `cylc config` parses the config file and prints the parsed result, so it should fail if there’s a syntax error. Can you do a targeted test to confirm that?

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [August 12, 2022, 4:59am UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/11 "2022-08-12T04:59:17Z")

</div>

> [@srennie](#):
>
> I can reproduce the issue of being unable to restart a workflow with a task removed.

Reproduced - I can confirm that’s a bug. Thanks for reporting!

The reload bit is a red herring, it’s just restart after removing a task from the config that’s a problem.

> <https://github.com/cylc/cylc-flow/issues/5057>
>
> Ref: https://cylc.discourse.group/t/task-wrangling-issues/517/9
> 
> Datastore iss…ue.
> 
> \`\`\`ini
> \[scheduling\]
> \[\[graph\]\]
> R1 = a & b
> \[runtime\]
> \[\[a, b\]\]
> script = false
> \`\`\`
> \- install, play, stop or kill once stalled
> \- remove b from the graph, reinstall, and play
> 
> \`\`\`
> 2022-08-12T17:05:12+12:00 INFO - LOADING task proxies
> 2022-08-12T17:05:12+12:00 INFO - + 1/a failed
> 2022-08-12T17:05:12+12:00 INFO - \[1/a failed(runahead) job:01 flows:1\] =\> failed
> 2022-08-12T17:05:12+12:00 INFO - Runahead limit: 1
> 2022-08-12T17:05:12+12:00 INFO - + 1/b failed
> 2022-08-12T17:05:12+12:00 ERROR - '~oliverh/bug/run1//$namespace|b'
> Traceback (most recent call last):
> File "/home/oliverh/cylc/cylc-flow/cylc/flow/data\_store\_mgr.py", line 824, in generate\_ghost\_task
> task\_def = self.data\[self.workflow\_id\]\[TASKS\]\[t\_id\]
> KeyError: '~oliverh/bug/run1//$namespace|b'
> During handling of the above exception, another exception occurred:
> Traceback (most recent call last):
> File "/home/oliverh/cylc/cylc-flow/cylc/flow/scheduler.py", line 645, in start
> await self.configure()
> File "/home/oliverh/cylc/cylc-flow/cylc/flow/scheduler.py", line 464, in configure
> self.\_load\_pool\_from\_db()
> File "/home/oliverh/cylc/cylc-flow/cylc/flow/scheduler.py", line 695, in \_load\_pool\_from\_db
> self.workflow\_db\_mgr.pri\_dao.select\_task\_pool\_for\_restart(
> File "/home/oliverh/cylc/cylc-flow/cylc/flow/rundb.py", line 859, in select\_task\_pool\_for\_restart
> callback(row\_idx, list(row))
> File "/home/oliverh/cylc/cylc-flow/cylc/flow/task\_pool.py", line 496, in load\_db\_task\_pool\_for\_restart
> self.add\_to\_pool(itask, is\_new=False)
> File "/home/oliverh/cylc/cylc-flow/cylc/flow/task\_pool.py", line 211, in add\_to\_pool
> self.create\_data\_store\_elements(itask)
> File "/home/oliverh/cylc/cylc-flow/cylc/flow/task\_pool.py", line 237, in create\_data\_store\_elements
> self.data\_store\_mgr.increment\_graph\_window(itask)
> File "/home/oliverh/cylc/cylc-flow/cylc/flow/data\_store\_mgr.py", line 654, in increment\_graph\_window
> is\_orphan = self.generate\_ghost\_task(s\_tokens.id, itask, is\_parent)
> File "/home/oliverh/cylc/cylc-flow/cylc/flow/data\_store\_mgr.py", line 826, in generate\_ghost\_task
> task\_def = self.added\[TASKS\]\[t\_id\]
> KeyError: '~oliverh/bug/run1//$namespace|b'
> 2022-08-12T17:05:12+12:00 CRITICAL - Workflow shutting down - '~oliverh/bug/run1//$namespace|b'
> \`\`\`

---

<div class="post-metadata">

**Author:** ![srennie](https://avatars.discourse-cdn.com/v4/letter/s/8edcca/32.png) [@srennie](https://cylc.discourse.group/u/srennie)\
**Post date:** [August 12, 2022, 6:05am UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/12 "2022-08-12T06:05:05Z")

</div>

Okay, I have not been able to reproduce the issue of cylc config showing me a different task environment to what is in the job script. cylc config is now giving me parsing errors if the workflow is invalid (I don’t recall if that’s what I saw the other day). I’m not really sure how I got to that state. But I will have a better idea of what to look for in future in case it happens again.

---

<div class="post-metadata">

**Author:** ![srennie](https://avatars.discourse-cdn.com/v4/letter/s/8edcca/32.png) [@srennie](https://cylc.discourse.group/u/srennie)\
**Post date:** [August 12, 2022, 7:31am UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/13 "2022-08-12T07:31:28Z")

</div>

I can reproduce it in my complex suite.

> (productive) gadi-login-04:dp9 run1 $ cylc reinstall  
> REINSTALLED suite\_test/run1 from /g/data/dp9/sjr548/suite\_test  
> (productive) gadi-login-04:dp9 run1 $ cylc reload suite\_test  
> Done  
> (productive) gadi-login-04:dp9 run1 $ cylc validate .  
> Valid for cylc-8.0rc3  
> (productive) gadi-login-04:dp9 run1 $ cylc trigger suite\_test //20220321T0600Z/pfx\_um\_recon\_cold  
> Done  
> (productive) gadi-login-04:dp9 run1 $ less log/job/20220321T0600Z/pfx\_um\_recon\_cold/NN/job  
> (productive) gadi-login-04:dp9 run1 $ cylc config suite\_test \> parsed\_conf  
> (productive) gadi-login-04:dp9 run1 $ less parsed\_conf

contents of job script

> # Job submit method: background

contents of parsed\_conf

> [[pfx\_um\_recon\_cold]]  
> script = rose task-run --verbose --verbose --path=“site/nci/bin”  
> platform = PBS  
> …  
> [[[directives]]]  
> -W umask = 0022  
> -P = dp9  
> -l storage = gdata/dp9+gdata/access+scratch/access+gdata/ig2  
> -q = normal  
> -l ncpus = 16  
> -l mem = 64G

And then I modified the -l storage directives, reinstalled and reloaded. cylc config shows the updated detail. If I retrigger the task, it is still submitting to the background. (I had forgotten to inherit the HPC family to set the platform originally.) So it is persistently wrong. I have managed to run via PBS for another task, so that should be correctly configured.

Now I think about it, the previous case also involved modifications to inheritance. Could this somehow be a causal factor to the task config getting stuck in the past?

---

<div class="post-metadata">

**Author:** ![srennie](https://avatars.discourse-cdn.com/v4/letter/s/8edcca/32.png) [@srennie](https://cylc.discourse.group/u/srennie)\
**Post date:** [August 12, 2022, 7:36am UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/14 "2022-08-12T07:36:24Z")

</div>

stopping and restarting the suite got the task to update to run on PBS.

Is there a way to preview a jobscript? So I can check changes before triggering the task.

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [August 15, 2022, 10:25pm UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/15 "2022-08-15T22:25:52Z")

</div>

Jobscripts are generated at the last moment before job submission, and Cylc 8 doesn’t provide a way to “preview” one because it complicates the handling of job submission number and workflow provenance.

You can manually trigger the task, and look at the resulting job script then. Another good reason to use a quick dummy workflow to figure out issues like this - as Cylc does not care if the task runs “sleep 10” or a massive scientific model.

By the way, I was unable to reproduce this problem the other day (forgot to post another reply, sorry). If it works in a dummy workflow it should work in your real one, if the platform and job runner are the same. If you confirm again that the dummy case works, try looking for more information in the logs of the real case (job.out, job.err, job.activity, and the scheduler log).

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [August 26, 2022, 3:11am UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/16 "2022-08-26T03:11:19Z")

</div>

@srennie - we might have run into your reload bug; can you confirm you were running in backward compatibility mode above? (which is switched on by the old `suite.rc` config filename).

---

<div class="post-metadata">

**Author:** ![srennie](https://avatars.discourse-cdn.com/v4/letter/s/8edcca/32.png) [@srennie](https://cylc.discourse.group/u/srennie)\
**Post date:** [August 26, 2022, 3:41am UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/17 "2022-08-26T03:41:06Z")

</div>

No, I was working in a pure cylc8 suite, no legacy files at all.

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [August 26, 2022, 3:41am UTC](https://cylc.discourse.group/t/task-wrangling-issues/517/18 "2022-08-26T03:41:43Z")

</div>

OK, so much for that idea - thanks!