Kind of request
Something else
Problem
analyzer/redact_fuzz_test.go defines FuzzRedact, but no workflow runs it:
$ grep -rn 'fuzz\|Fuzz' .github/workflows/
$
Under go test a fuzz target only executes its seed corpus, so the target runs but never actually fuzzes. The property it guards is a real one — Redact must never leave a literal byte in its output, and it gets there through hand-rolled index arithmetic over escape sequences and dollar-quoted tags, scanning under two dialect readings and taking the union.
That lexer is the single highest-consequence piece of string handling in the repo: everything it misses becomes PII in a Result.Query that ships to a log sink, and a panic in it happens on the caller's query path. It has already been the site of two real bugs (see the Redact / IsMultiStatement section in AGENTS.md).
Proposed solution
Add a scheduled fuzz job — go test -fuzz=FuzzRedact -fuzztime=Nm ./analyzer/ — on a nightly or weekly cron rather than per-PR, so it cannot add minutes to every push.
Commit any crasher the run finds to testdata/fuzz/FuzzRedact/, which then becomes part of the seed corpus and is replayed by the ordinary make test from then on.
Worth checking at the same time whether Fingerprint and IsMultiStatement deserve targets of their own: both walk the same lexer, and IsMultiStatement fails closed for a security reason (it is what stops a smuggled statement reaching the always-rolled-back EXPLAIN tx), so a missed separator there has a sharper consequence than a missed literal.
Alternatives considered
Running it per-PR with a short -fuzztime would catch less and slow every push; the corpus-replay behaviour of make test already covers the regression case once a crasher is committed.
Leaving it as-is is the status quo: the target exists, reads as covered, and does nothing beyond its seeds.
Additional context
Noted repeatedly during the 0.3/0.4 release work and never filed. Not a regression, and nothing is known to be broken — this is about a guard that is not actually on.
Kind of request
Something else
Problem
analyzer/redact_fuzz_test.godefinesFuzzRedact, but no workflow runs it:$ grep -rn 'fuzz\|Fuzz' .github/workflows/ $Under
go testa fuzz target only executes its seed corpus, so the target runs but never actually fuzzes. The property it guards is a real one —Redactmust never leave a literal byte in its output, and it gets there through hand-rolled index arithmetic over escape sequences and dollar-quoted tags, scanning under two dialect readings and taking the union.That lexer is the single highest-consequence piece of string handling in the repo: everything it misses becomes PII in a
Result.Querythat ships to a log sink, and a panic in it happens on the caller's query path. It has already been the site of two real bugs (see theRedact/IsMultiStatementsection in AGENTS.md).Proposed solution
Add a scheduled fuzz job —
go test -fuzz=FuzzRedact -fuzztime=Nm ./analyzer/— on a nightly or weekly cron rather than per-PR, so it cannot add minutes to every push.Commit any crasher the run finds to
testdata/fuzz/FuzzRedact/, which then becomes part of the seed corpus and is replayed by the ordinarymake testfrom then on.Worth checking at the same time whether
FingerprintandIsMultiStatementdeserve targets of their own: both walk the same lexer, andIsMultiStatementfails closed for a security reason (it is what stops a smuggled statement reaching the always-rolled-back EXPLAIN tx), so a missed separator there has a sharper consequence than a missed literal.Alternatives considered
Running it per-PR with a short
-fuzztimewould catch less and slow every push; the corpus-replay behaviour ofmake testalready covers the regression case once a crasher is committed.Leaving it as-is is the status quo: the target exists, reads as covered, and does nothing beyond its seeds.
Additional context
Noted repeatedly during the 0.3/0.4 release work and never filed. Not a regression, and nothing is known to be broken — this is about a guard that is not actually on.