Bug #17072
closedlocal variable 'result' referenced before assignment
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
Updated by Peter Amstutz about 4 years ago
- Status changed from New to In Progress
Updated by Peter Amstutz about 4 years ago
- Target version changed from 2020-11-04 Sprint to 2020-11-18
Updated by Peter Amstutz about 4 years ago
- Target version changed from 2020-11-18 to 2020-12-02 Sprint
Updated by Peter Amstutz about 4 years ago
This will be fixed in upstream cwltool, I'll have to update when the fix is merged and released.
Updated by Peter Amstutz about 4 years ago
17072-update-cwltool @ 1cfcb49baf325386a409a1fe549dfb61e4982496
Update cwltool which fixes the original error (unbound variable 'result')
Also adjusts the default submit thread concurrency to 4.
Updated by Lucas Di Pentima about 4 years ago
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.
Updated by Peter Amstutz about 4 years ago
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.
Updated by Peter Amstutz about 4 years ago
- Status changed from In Progress to Resolved