Demultiplexing from only read2 barcodes pushes all outputs to untrimmed

[elliot-imler]

• Cutadapt v5.1 installed via pip and Python version 3.11.12
  Was trying to do some secondary demultiplexing and came across what I believe to be an issue handling paired read demultiplexing:

    cutadapt \
        -U 28 \
        -G ^file:"$BARCODE_FILE" \
        -o $OUTPUT_DIR/${base_name}-{name}_R1.fastq.gz \
        -p $OUTPUT_DIR/${base_name}-{name}_R2.fastq.gz \
        --untrimmed-output $OUTPUT_DIR/${base_name}_unknown_R1.fastq.gz \
        --untrimmed-paired-output $OUTPUT_DIR/${base_name}_unknown_R2.fastq.gz \
        --cores $cores_per_file \
        "$r1_file" "$r2_file" > "$log_file" 2>&1

This properly finds the barcodes and performs trimming according to the log file (not attached due to proprietary sample naming) but all reads are output to the "unknown" file instead of individual output files...
Thought it was an issue parsing the {name} barcode replacement string but simply switching the read inputs and making it a read1 barcode gives the expected behavior:

    cutadapt \
        -u 28 \
        -g ^file:"$BARCODE_FILE" \
        -o $OUTPUT_DIR/${base_name}-{name}_R2.fastq.gz \
        -p $OUTPUT_DIR/${base_name}-{name}_R1.fastq.gz \
        --untrimmed-output $OUTPUT_DIR/${base_name}_unknown_R2.fastq.gz \
        --untrimmed-paired-output $OUTPUT_DIR/${base_name}_unknown_R1.fastq.gz \
        --cores $cores_per_file \
        "$r2_file" "$r1_file" > "$log_file" 2>&1

I'm not sure if this is intended, for example requiring {name1} and {name2} for paired reads, but I don't think it is clear from the documentation as i understand it.

[marcelm]

This is intentional (or you could say a a known limitation). See https://cutadapt.readthedocs.io/en/stable/guide.html#demultiplexing:

Paired-end demultiplexing always uses the adapter matches of the first read to decide where a read should be written. If adapters for read 2 are given (-A/-G), they are detected and removed as normal, but these matches do not influence where the read pair is written. This is to ensure that read 1 and read 2 are always synchronized.

Even the trick you found yourself is documented:

To demultiplex using a barcode that is located on read 2, you can “cheat” and swap the roles of R1 and R2 for both the input and output files
[...]
If you do this in a script or pipeline, it may be a good idea to add a comment to clarify that this reversal of R1 and R2 is intended.

The problem is that it would be unclear what {name} refers to when a user provides adapters for both R1 and R2.

Maybe it would be nice for Cutadapt to support {name1} and {name2} in cases like this as a way to remove the ambiguity. Currently, {name1} and {name2} can only be used together (for combinatorial demultiplexing).

[elliot-imler]

My apologies! I read right over that obviously very relevant section... I've run into similar 'bugs' in paired-read processing software before which is why I knew to try that trick. I'll leave it up to you whether it seems worth changing, but i'm fine with just keeping the read reversal hack for now. Cheers!