Nextflow: Shell template invalid caching

Created on 12 Dec 2019  路  2Comments  路  Source: nextflow-io/nextflow

Bug report

Caching not activated when params setting inserted in script changes.

Expected behavior and actual behavior

Expect caching not to happen.
Caching actually happens.

Steps to reproduce the problem

The following script:

process foo {

  echo true

  shell:
  '''
  echo !{params.somesetting}
  '''
}

when run twice with changing values of somesetting uses the cached process for the second invocation:

bc-32-1-08,it/cellgeni/patterns (master *%) (pat) nextflow run foo.nf -ansi-log false --somesetting foobar3
N E X T F L O W  ~  version 19.10.0
Launching `foo2.nf` [determined_laplace] - revision: 9324748d96
[b1/e4b29d] Submitted process > foo
foobar3
bc-32-1-08,it/cellgeni/patterns (master *%) (pat) nextflow run foo.nf -ansi-log false --somesetting foobar4 -resume
N E X T F L O W  ~  version 19.10.0
Launching `foo2.nf` [lethal_brenner] - revision: 9324748d96
[b1/e4b29d] Cached process > foo
foobar3

The following script does not exhibit this behaviour and works as expected:

process foo {

  echo true

  shell:
  setting = params.somesetting
  '''
  echo !{setting}
  '''
}

Program output

(Copy and paste here output produced by the failing execution. Please highlight it as a code block. Whenever possible upload the .nextflow.log file.)

Environment

  • Nextflow version:
    See above
  • Java version:
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-b04)
OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)
  • Operating system:
NAME="Red Hat Enterprise Linux Server"
VERSION="7.6 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.6"
kinbug

Most helpful comment

Running nextflow with -dump-hashes reveals the issue here. With !{params.somesetting}, nextflow just look at the string and see that the initial string didn't change. Basically, the code is not aware of the new string interpolation syntax. I tried it again with ${params.somesetting} and it indeed works as expected.

All 2 comments

Running nextflow with -dump-hashes reveals the issue here. With !{params.somesetting}, nextflow just look at the string and see that the initial string didn't change. Basically, the code is not aware of the new string interpolation syntax. I tried it again with ${params.somesetting} and it indeed works as expected.

This was more tricky than expected! Thanks for spotting it!

Was this page helpful?
0 / 5 - 0 ratings