Bug #17072
closed
local variable 'result' referenced before assignment
Added by Peter Amstutz about 4 years ago.
Updated over 3 years ago.
Release relationship:
Auto
Description
Reported that a workflow that previously worked is failing with this error:
2020-11-03T13:11:13.153103185Z [1;30mERROR [0m [31m[container parentalGenomeAssembly_4] unable to collect output from fbe5a25467a21bb4ce5f8282cab7a047+12407:
2020-11-03T13:11:13.153103185Z ("Error collecting output for parameter 'assemblies':\n../../lib/cwl/workflow.json:1:56701: local variable 'result' referenced before assignment", {}) [0m
- Description updated (diff)
- Status changed from New to In Progress
- Target version changed from 2020-11-04 Sprint to 2020-11-18
- Target version changed from 2020-11-18 to 2020-12-02 Sprint
This will be fixed in upstream cwltool, I'll have to update when the fix is merged and released.
I have a couple questions:
- Do you think we could spare testing cwltool’s
TaskQueue
class, assuming it’s being tested there?
- Changing nr of default threads from 1 to 4 may change the runner's RAM requirements, that seems to be 1 GB by default. Do you think this should also be adjusted?
The rest LGTM.
Lucas Di Pentima wrote:
I have a couple questions:
- Do you think we could spare testing cwltool’s
TaskQueue
class, assuming it’s being tested there?
I forgot move the test over when I moved TaskQueue over. Will leave it for now but I'll move it over the cwltool in the future.
- Changing nr of default threads from 1 to 4 may change the runner's RAM requirements, that seems to be 1 GB by default. Do you think this should also be adjusted?
I don't think so. What the threads are doing is pretty lightweight, and the keep client object and collection cache (which are the biggest memory consumers) are shared among them.
The rest LGTM.
Thanks, will merge.
- Status changed from In Progress to Resolved
Also available in: Atom
PDF