Bug #17072

local variable 'result' referenced before assignment

Added by Peter Amstutz 12 months ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
CWL
Target version:
Start date:
11/30/2020
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
-
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

Subtasks

Task #17088: Review 17072-update-cwltool ResolvedPeter Amstutz

Associated revisions

Revision f99e500a
Added by Peter Amstutz 11 months ago

Merge branch '17072-update-cwltool' refs #17072

Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <>

History

#1 Updated by Peter Amstutz 12 months ago

  • Description updated (diff)

#2 Updated by Peter Amstutz 12 months ago

  • Status changed from New to In Progress

#3 Updated by Peter Amstutz 12 months ago

  • Target version changed from 2020-11-04 Sprint to 2020-11-18

#4 Updated by Peter Amstutz 11 months ago

  • Target version changed from 2020-11-18 to 2020-12-02 Sprint

#5 Updated by Peter Amstutz 11 months ago

This will be fixed in upstream cwltool, I'll have to update when the fix is merged and released.

#6 Updated by Peter Amstutz 11 months ago

17072-update-cwltool @ 1cfcb49baf325386a409a1fe549dfb61e4982496

Update cwltool which fixes the original error (unbound variable 'result')

Also adjusts the default submit thread concurrency to 4.

https://ci.arvados.org/view/Developer/job/developer-run-tests/2198/

#7 Updated by Lucas Di Pentima 11 months 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.

#8 Updated by Peter Amstutz 11 months 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.

#9 Updated by Peter Amstutz 11 months ago

  • Status changed from In Progress to Resolved

#10 Updated by Peter Amstutz 5 months ago

  • Release set to 38

Also available in: Atom PDF