Skip to content

Sarek FASTQ samplesheets fail validation because BAM and BAI are always required #1297

Open

Description

@agammann

Summary

On main at 95bdacc803aa5cfdb10f35e5b9fb2d4b11100133, Sarek samplesheet generation reports missing BAM and BAI columns for FASTQ input.

Steps to reproduce

  1. Put two valid, paired gzip FASTQ files named T1-X_R1_001.fastq.gz and T1-X_R2_001.fastq.gz in ./fastqs. I used one record in each file: @read1, ACGT, +, !!!!.
  2. From the repository root, run:
python bio-research/skills/nextflow-development/scripts/generate_samplesheet.py ./fastqs sarek --input-type fastq -o sarek.csv

Observed behavior

The script finds and pairs both FASTQs into one row and infers tumor status 1, then reports:

Row 2: Missing required column 'bam'
Row 2: Missing required column 'bai'

Accepting the default N at Proceed anyway? exits 1 without writing a samplesheet. Adding --no-interactive prints the same errors, writes a sheet, and exits 0.

Expected behavior

A FASTQ row should not require BAM or BAI columns. The Sarek configuration applies those requirements only when the input type is BAM or CRAM.

Cause and verification

The validator collects every required column, then leaves the conditional check as pass. I reproduced the behavior on Windows with Python 3.14.8 using actual decompressible gzip FASTQs, in both interactive and noninteractive modes. I did not run the Nextflow pipeline.

Activity

  1. mansi-singh4 commented on Oct 11, 2026

    @mansi-singh4

    Hi @agammann
    if you are not already working on this issue i would like to take it up.

  2. agammann commented on Oct 11, 2026

    @agammann
    Author

    Thanks—please feel free to take it up.

  3. agammann commented on Oct 13, 2026

    @agammann
    Author

    A clarification to my earlier reply, @mansi-singh4: I reported the issue, and the maintainers handle upstream changes. The repo's external PR workflow is set up to close non-member PRs that change plugin code, so please check with a maintainer before investing time in a PR.

  4. mansi-singh4 commented on Oct 13, 2026

    @mansi-singh4

    3. A clarification to my earlier reply, @mansi-singh4: I reported the issue, and the maintainers handle upstream changes. The repo's external PR workflow is set up to close non-member PRs that change plugin code, so please check with a maintainer before investing time in a PR.

    yeah that had occurred to me too... but I am new to open source and have no idea how to contact with the maintainers here...

  5. agammann commented on Oct 14, 2026

    @agammann
    Author

    You can ask right here in this issue, @mansi-singh4. For example: "Could a maintainer advise whether an external fix for this bug would be welcome, and how I should submit it under the current PR policy?" Then give them time to respond before preparing a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions