Accept sequencing data without FastQs (BAM-first runs)

[davmlaw]

🤖 Written by Claude

Background

TAU diagnostics plan to stop storing FastQs (disk space), and some sequencers emit BAM directly with no FastQ stage at all. See SACGF/variantgrid_sapath#357.

The server side is done: BamFile now has its own mandatory sequencing_sample FK, and unaligned_reads became genuinely optional. The bulk create endpoint (seqauto/api/v1/sequencing_files/bulk_create) resolves the sample from the record's sample_name plus the sample sheet lookup, so a record consisting of just bam_file + vcf_file is now accepted. Records that do carry unaligned_reads behave exactly as before.

This client still makes FastQs mandatory, so it can't send a BAM-first run.

Wanted

1. SequencingFile.fastq_r1 / fastq_r2 become optional

src/variantgrid_api/data_models.py:185

fastq_r1: Optional[str] = field(default=None, metadata=config(exclude=lambda x: x is None))
fastq_r2: Optional[str] = field(default=None, metadata=config(exclude=lambda x: x is None))

2. Build the unaligned_reads block only when there are FastQs

src/variantgrid_api/api_client.py:174-181 — create_sequencing_data() currently pops fastq_r1/fastq_r2 unconditionally and always nests them under unaligned_reads. Build that block when fastq_r1 is set; otherwise send the record with bam_file / vcf_file alone and let the server resolve the sample from sample_name.

3. New example showing a BAM-first run

Alongside examples/example_haem_20_999.py — same shape, no FastQ paths.

4. CHANGELOG entry and version bump

Current version is 1.3.2.

Compatibility

Existing callers that pass fastq_r1/fastq_r2 keep sending the same payload and hit the same server behaviour, so this is additive on both sides. The server populates BamFile.sequencing_sample for FastQ-carrying records too, whether or not the client names the sample explicitly.