Strange results file checking behavior that breaks workflows at nested mapnodes in nipype 1.2.3

[dPys]

Summary

Nested MapNodes hang in some workflows when trying to load the node's result file. It appears this is because results.outputs.get() fails since there is a Bunch representation of outputs, rather than a dictionary representation.

Manifests as follows:

At the logging debug level during execution:

Outputs object of loaded result /private/tmp/work/20191012-164048_df69a011-5615-4010-aa22-d4a0c94c5696_wf_single_subject_fmri_0025427/wf_single_sub_0025427_fmri_20191012-164047/meta_wf_0025427/fmri_connectometry_0025427/thresh_func_node/result_thresh_func_node.pklz is a Bunch.

and then if I attempt to load the file manually:

In [32]: res.outputs.get()                                                                                                                                                     
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-32-347df97b2ed0> in <module>
----> 1 res.outputs.get()

/usr/local/anaconda3/lib/python3.7/site-packages/nipype-2.0.0.dev0+g7b9c63932-py3.7.egg/nipype/interfaces/base/support.py in get(self, *args)

TypeError: get expected at least 1 arguments, got 0

See attached example results file:
result_thresh_func_node.pklz.zip

Interestingly, it seems that load_resultfile from nipyp/epipeline/engine/utils.py fails, but only for the result file of the primary node (i.e. and not its subnodes if they get parameterized)

Appears to only occurs as of version nipype 1.2.3. Looks like this might also be related to #3009 #3014 #3075 and/or #1798 of fmriprep.

Any ideas @oesteban ?

@dPys

[oesteban]

Does #3075 help in any way? Are you able to produce a replicable sample of this issue?

[dPys]

#3705 does not appear to help with the issue unfortunately, but it might be nice to include whatever the fix will be into that PR if it is indeed related?

If you'd like to reproduce it with your own fmriprep outputs you could pip install pynets==0.9.64 and then run something like:

pynets -p 1 -mod 'partcorr' -min_thr 0.05 -max_thr 1.00 -step_thr 0.05 -sm 0 1 -ua '{path to 
 PyNets}/pynets/core/atlases/DesikanKlein2012.nii.gz' -anat '{Path to fMRIprep derivatives}/fmriprep/sub-0025427/ses-1/anat/sub-0025427_space-MNI152NLin2009cAsym_desc-preproc_T1w_masked.nii.gz' -func '{Path to fMRIprep derivatives}/fmriprep/sub-0025427/ses-1/func/sub-0025427_ses-1_task-rest_space-MNI152NLin2009cAsym_desc-smoothAROMAnonaggr_bold_masked.nii.gz' -conf '{Path to fMRIprep derivatives}/fmriprep/sub-0025427/ses-1/func/sub-0025427_ses-1_task-rest_desc-confounds_regressors.tsv' -m '{Path to fMRIprep derivatives}/fmriprep/sub-0025427/ses-1/func/sub-0025427_ses-1_task-rest_space-MNI152NLin2009cAsym_desc-brain_mask.nii.gz' -id '0025427' -pm "4,8"

Just be sure that whatever anatomical and functional images you use are skull stripped. When using nipype <1.2.3, it should not hang and the wf should finish in 10 min or so. If using nipype 1.2.3, the wf will hang after running the thresh_func_node mapnode, where its outputs get mapped to an outputnode that connects back to the parent workflow of functional_connectometry_* -- specifically (pass_meta_ins_node/pass_meta_outs_node) that live in meta_wf_*

@dPys