[alex-powell]

Fixes #1383

What

validateOptions now rejects a --batch-size that is not a positive integer, with --batch-size must be a positive integer and exit 1. An omitted or empty value still falls back to the default of 100.

Why

chunk() advances with i += size, so a size of 0 never advances and a negative size walks backward. Either one pushes slices until Node aborts with a heap out of memory crash. Non-numeric input became NaN and ended in a misleading OSV/CA certificate error.

Before

$ cve-lite . --batch-size 0
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
(exit 134)

After

$ cve-lite . --batch-size=0
Error: --batch-size must be a positive integer
(exit 1)
$ cve-lite . --batch-size=5
(scan runs normally, exit 0)

Tests

• New cases in tests/validate.test.ts: 0, -1, abc, 1.5, 10abc rejected; 1, 100 accepted. They failed before the change.
• npm run build and full npm test pass.

The check lives in validate.ts rather than args.ts, so it does not overlap with #1382.

[Copilot]

🟢 Approval recommended

The focused validation addresses the reported failures, preserves default handling, and includes targeted regression tests.

No open issues 🎉

What changed in this PR

Adds early validation for --batch-size to prevent invalid values from causing runaway memory allocation or misleading OSV errors.

Changes:

• Rejects zero, negative, fractional, and non-numeric values with a clear error.
• Preserves the default behavior for omitted or empty values.
• Adds regression tests for invalid inputs and valid positive integers.

File	Description
tests/​validate.test.ts	Adds rejection and acceptance cases for batch-size validation.
src/​cli/​validate.ts	Validates non-empty batch-size values before scanning.

_{Review effort: Balanced}

[sonukapoor]

Approving. The failure mode here is worse than it reads on paper.

--batch-size 0 and --batch-size -1 do not error, they exhaust the heap. The chunker steps its index by whatever size it is given, so zero stays where it is and a negative walks backward, and both loop until the process dies at exit code 134. --batch-size abc is stranger: it exits 1 having printed advice about installing a corporate certificate authority, so the first thing a user sees after a typo is an instruction to reconfigure their network.

Your guard rejects all of that up front with one message that names the flag, and a valid value still scans normally. I also tried 1.5 and 10abc, which the digits-only test catches, and an empty value, which correctly falls through to the default.

The comment explaining why both zero and a negative loop is the part I would have left out myself, and it is the reason the next person will not weaken this into a simple non-zero check.

Merge result clean against current main at 177 suites and 2,471 tests. Removing the guard fails 5 of the 41 tests in that file and leaves 36 passing.

One note rather than a change request: the certificate advice appearing at all is not something #1336 should have caught, because that path genuinely routes as a network error rather than a flag error. Stopping it at the parser instead is the right answer.