fix(krakenuniq/preloadedkrakenuniq): fix --preload-size handling, report optionality, and simplify stub

[mahesh-panchal]

PR checklist

Three related fixes to krakenuniq/preloadedkrakenuniq, found while auditing the module.

1. --preload-size was silently dropped

ext.args feeds the module's separate preload warm-up call, ext.args2
feeds the actual classify call. Per KrakenUniq's own docs, --preload-size
overrides --preload and runs on the classify invocation itself, not a
separate step - so it belongs in ext.args2. But the code that decides
whether to skip the separate warm-up checked task.ext.args instead, so a
user setting --preload-size via ext.args (as the existing test did) had
it silently dropped entirely: the warm-up was skipped, and the flag never
reached classify either, since that only reads ext.args2.

Also fixes an independent typo in the stub, where args2 read from
task.ext.args instead of task.ext.args2 - a regression PR #11939 fixed
in script: but missed in stub:.

2. report_file: false crashed the process

The report output wasn't marked optional: true despite only being
created when report_file is true - so disabling it made Nextflow fail the
task with a missing-output-file error, even though the run itself succeeded.

3. Stub was needlessly complex

The stub duplicated the entire script: command-construction logic (preload
command, args, per-flag options, --paired branching) just to produce an
unused echo krakenuniq ... line - none of it affects which files actually
get created. Per the nf-core module spec, a stub only needs to produce
correctly named placeholder files. Simplified from ~100 duplicated lines to
an ~18-line loop over the batch's prefixes; verified byte-identical output
against the existing snapshots.

• This comment contains a description of changes (with reason).
• If you've fixed a bug or added code that should be tested, add tests!
• Ensure that the test works with either Docker / Singularity. Conda CI tests can be quite flaky:
  • For modules:
    • nf-core modules test krakenuniq/preloadedkrakenuniq --profile docker
    • nf-core modules test krakenuniq/preloadedkrakenuniq --profile singularity
    • nf-core modules test krakenuniq/preloadedkrakenuniq --profile conda

🤖 Generated with Claude Code

[erikrikarddaniel]

Reviewed with some help from entirely by Claude Code.

Checked all three fixes carefully rather than trusting the description, and I think they're all correct:

1. --preload-size fix: confirmed by reading the full (untouched) classify command that ${args2} is what actually reaches krakenuniq in both the single-end and paired branches, so checking args2 for --preload-size (rather than args) is the right place -- the old code's check against task.ext.args meant a flag set the way the original test set it (ext.args = '--preload-size 1GB') was silently ineffective twice over: the separate warm-up ran anyway (since args didn't have the string either, in the fixed check's frame), and the flag itself never reached classify since that only ever read args2. The new "sarscov2 - Illumina FASTQ single" test reads the real rendered .command.sh and asserts --preload --threads is absent -- traced this by hand against the old code and confirmed that specific assertion would actually have failed there, so it's a genuine regression test, not just decoration.
2. optional: true on report: straightforward, matches the pattern the other three outputs already use, and the new "no optional outputs" test exercises the exact all-four-off case that used to crash.
3. Stub simplification: traced the new merged_suffix logic against both deleted branches side by side for all four file patterns (classified/unclassified txt and gz, single vs. paired) -- byte-for-byte equivalent to what was there before. Confirmed the always-create-everything-regardless-of-flags behavior isn't a change either; the old stub did the same, the boolean-driven variables were only ever used inside the now-deleted unused echo krakenuniq ... line.

One thing worth a thought, not a blocking issue: now that --preload-size is only honoured via ext.args2, what happens to a user who -- understandably, given the original test itself made exactly this mistake -- still sets it via ext.args? As I read it, preload_mode would come out true (since args2 doesn't have the string), so the separate warm-up runs with --preload-size folded into args alongside --preload itself, which per KrakenUniq's own docs (--preload-size overrides --preload) sounds like a genuinely contradictory combination to hand it, rather than just a dropped flag. Not a regression from this PR -- the old code mishandled that case differently, not better -- and possibly out of scope for a bug-fix PR to also add misuse detection for a free-form ext.args/ext.args2 string. Just flagging in case it's worth a one-line note in meta.yml about where the flag belongs, given it's apparently an easy mistake to make.

Nothing else stood out. LGTM.

[erikrikarddaniel]

Traced this against the untouched classify command below (${args2} is what actually reaches krakenuniq in both branches) -- checking args2 here is correct. See the review body for the one open question this raised (what happens if a user sets --preload-size via ext.args instead, matching what the original test itself did).

[mahesh-panchal]

Merging and will let taxprofiler know about the change.