[theontho]

FASTQ extraction left the CRAM-reading samtools view process single-threaded even when the caller requested several threads. Pass the requested thread count to this stage, alongside the existing collate and fastq thread arguments, so CRAM decoding can overlap the downstream work.

The existing pipeline test now checks that every stage receives the requested thread count. Real 2 Mb and whole-chr20 extraction was run on native Linux and a native-tools Windows VM, with decoded paired FASTQ contents checked across both versions and platforms. Full-genome installed native-Windows correctness has now passed: both FASTQ mates contain 339,819,948 records and exactly match the decoded Linux SHA-256 values; full SNP and microarray correctness also passed. Local evidence (ignored, not GitHub-hosted): out/full-validation/final-installed-correctness.json in the rollout worktree.

Local validation on this branch: Ruff check/format, mypy (123 source files), site and Actions validation, 1880 ordinary tests passed (30 skipped, 87 deselected), fake-data E2E 22 passed (8 optional-path skips), real hg19-mini smoke 44 passed, and pre-commit passed. The first matched Linux VM 2 Mb SNP cohort passed 1 warmup and 3 measured runs with exact decoded VCF body versus the prior golden. All five matched-VM performance workloads subsequently passed with exact outputs and Windows/Linux ratios at or below 1.20. After merging current main, Ruff check/format, mypy (124 source files), site validation, actionlint, and Actions validation passed again.

Initial observed chr20 elapsed times with --threads 2 --memory 512M: Windows 49.27s control / 42.99s candidate; native Linux 44.17s control / 34.65s candidate. These single serialized measurements were exploratory; native Linux is a reference, and the accepted performance gate is the completed matched Windows/Linux VM comparison above.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

• Source mode: Auto
• Repository: theontho/wgsextract-cli
• Branch: experiment/fastq-view-threads
• File: .coderabbit.yaml
• Commit: d9f245a
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: 4a12d485-5519-49fe-af73-d77e50f4ccb4

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

🟢 Approval recommended

No active review issues block the change enabling threaded CRAM decoding in FASTQ extraction.

No open issues 🎉

What changed in this PR

This PR enables threaded CRAM decoding in the FASTQ extraction pipeline by passing the requested thread count to samtools view, matching the existing downstream stages.

Changes:

• Adds -@ with the requested thread count to samtools view.
• Updates the pipeline test to request three threads and verify that every stage receives that count.

File	Description
tests/​test_alignment_commands.py	Verifies thread-count propagation across all pipeline stages.
src/​wgsextract_cli/​commands/​_extract_helpers.py	Enables threading in the alignment-reading stage of FASTQ extraction.

_{Review effort: Balanced}