Report consolidation fails when using a bids filter file if there are more than four sessions

[Jolinda]

What happened?

I have a study with multiple sessions and I wish to only process a session called "wave1". I use a bids filter file that contains:

{
"t1w": {
"datatype": "anat",
"session": "wave1"
},
"bold": {
"datatype": "func",
"session": "wave1"
},
}

If a subject has four or fewer sessions, I get a single sub-XXX_func.html report. However, if they have five sessions, I get the following empty files:
sub-XXX_ses_w_func.html
sub-XXX_ses_a_func.html
sub-XXX_ses_v_func.html
sub-XXX_ses_e_func.html
sub-XXX_ses_1_func.html

If I don't use the bids filter file, I get a report for each session, as expected.

What command did you use?

apptainer run --bind ${outdir}:/output,${bidsdir}:/bids \
              --cleanenv fmriprep.simg /bids /output participant \
              --participant-label ${subject} \
              --bids-filter-file wave1.json \
              --fs-license-file=freesurfer_license.txt \
              --reports-only

What version of fMRIPrep are you running?

24.1.1

How are you running fMRIPrep?

Singularity

Is your data BIDS valid?

Yes

Are you reusing any previously computed results?

No

Please copy and paste any relevant log output.

No response

Additional information / screenshots

No response

[effigies]

The issue is that the report generator assumes that you have sessions in a list:

{
    "t1w": {
        "datatype": "anat",
        "suffix": "T1w",
        "session": ["wave1"]
    },
    "bold": {
        "datatype": "func",
        "suffix": "bold",
        "session": ["wave1"]
    },
}

Will open an issue to fix this.

[effigies]

Also please note that you shouldn't remove the suffix. If there are any other NIfTI files with different suffixes, fmriprep will attempt to process them as if they were T1w and bold.

[Jolinda]

Ah, thanks, I will edit the filter file.

[Jolinda]

I know this has been closed for a couple of months but I wanted to at least add a note regarding the second part of my issue: why was this only happening when there were more than four sessions? There's an optional parameter --aggregate-session-reports with an undocumented default value of 4. My suggestion is to include the default value in the usage notes. I would probably have assumed this would be tested against the number of sessions in the input AFTER the filter, not before, so a note about that would also be helpful.