SRA.py / ncbi_upload.py resolve fastqs non-recursively: -r on a run folder silently builds an empty submission

[wilke]

Summary

SRA.py and ncbi_upload.py resolve fastqs non-recursively. Pointing
sra-upload -r at a run folder instead of a batch directory therefore yields an
empty submission, with a log line rather than an error.

Location

lib/python/SRA.py:145-158

for fastq in glob.glob(dir + "/*.fastq*") :

and lib/python/ncbi_upload.py:305

os.path.isfile(os.path.join(args.sequence_dir, fq))

Failure mode

Modern layout is <run>/<date>_fastq[s]/<BATCH>/*.fastq.gz, so a run folder is
two levels above the fastqs. -r <run folder> produces:

INFO Found 0 files.

and the run continues to build a submission with no runs in it.

This is not hypothetical: 250106_VH01674_75_AAGFWJWM5/SRA/ sits at the run-folder
level while its fastqs are in 250106_fastq/250106_Direct_276_277/, so
-r on that run folder is exactly the shape that silently produces nothing.

The SOP currently prevents this with prose (bin/sra-upload:139 hints the right
path), which works until it doesn't.

Suggested fix

Fail loudly rather than proceeding. If read_sequence_dir() finds zero fastqs,
exit non-zero with a message naming the directory searched — an empty submission
is never a valid outcome.

Optionally, detect the case: if the target has no fastqs but a child directory
does, say so explicitly ("found 0 fastqs in X; did you mean X/_fastq/?").

Related layout wrinkle

SRA/ lives inside the batch dir in the modern layout and at the run-folder root
in older ones, so any fix should treat both as legitimate rather than assuming one.

Provenance

reports/work-260730.seqtrack.md.