fix: validate redact max bytes

[Sushanth012]

Summary

• reject malformed or non-positive gstack-redact --max-bytes values with a usage error
• keep the redaction engine fail-closed by falling back to the default cap for invalid maxBytes values
• add CLI and engine regression tests for invalid caps

Fixes #1824

Testing

• bun test test/redact-engine.test.ts test/gstack-redact-cli.test.ts

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[trunk-io]

An error occurred while submitting your PR to the queue: Only users that are a part of this repo's Trunk organization or have write permissions to the repo can submit a PR to the queue

[jbetala7]

Heads-up on a duplicate: this targets the same issue (#1824) and lands effectively the same fix as #1825, which I opened on Jun 1 (4 days before this). Both changes are nearly line-for-line equivalent:

• add a positive-integer guard in bin/gstack-redact buildOpts() that exits 1 with gstack-redact: --max-bytes must be a positive integer
• harden scan() in lib/redact-engine.ts so an invalid cap (NaN/0/negative) falls back to DEFAULT_MAX_BYTES instead of letting byteLen > NaN silently flip the fail-closed oversize guard to fail-open
• add CLI + engine regression tests covering NaN/0/-1

Flagging so triage can dedupe — #1825 is the earlier surface for #1824 (which I also filed). Your implementation is correct too; the only minor delta is #1825 also rejects non-integer floats like 10.5 at the CLI and includes that in the test matrix. Not trying to step on the work, just keeping the lineage clean for the maintainer.

[jbetala7]

Overlap flag: this targets the same issue (#1824) and the same fail-open -> fail-closed fix as the earlier open PR #1825, opened 2026-06-01 (the same day #1824 was filed). Both touch the identical four files - bin/gstack-redact, lib/redact-engine.ts, test/gstack-redact-cli.test.ts, test/redact-engine.test.ts - with the same shape:

• engine: replace opts.maxBytes ?? DEFAULT_MAX_BYTES with a finite-and-positive guard that falls back to DEFAULT_MAX_BYTES
• CLI: reject a malformed --max-bytes with a usage error and exit 1
• tests: scan() with NaN/-1/0 on a large input still fails closed (this PR uses 2 MiB, exactly the case in the issue writeup), plus CLI tests for notanumber/-5

So this is a near-identical duplicate of #1825 - only one can land, since they edit the same lines. Flagging so a maintainer can pick the canonical one rather than have the two conflict. Good to see the fix converge independently; that is solid confirmation the fail-closed fallback is the right call. (Disclosure: #1825 is mine, so I am flagging the collision rather than asserting which should win - maintainer's call.)

One small note for whichever lands: this PR's engine guard Number.isFinite(opts.maxBytes) && opts.maxBytes > 0 accepts a non-integer cap (e.g. maxBytes: 100.5) at the engine layer while the CLI rejects floats via Number.isInteger; #1825 rejects non-integer at both layers. Functionally equivalent for the security guard either way.

[garrytan]

Closing in favor of #1825, which fixes the same --max-bytes validation but frames it around the fail-closed oversize guard (the security-load-bearing property) and includes a fail-open repro. Same files, can't land both. Thanks for the fix — feel free to weigh in on #1825.