LibGenParseMetaFindExpanderTest.testFindExpanderMatchesReference exhausts its vm.assume budget before finishing when run at more than the configured number of fuzz runs.
FOUNDRY_FUZZ_RUNS=8192 forge test --match-contract LibGenParseMeta
[FAIL: `vm.assume` rejected too many inputs (65536 allowed)]
testFindExpanderMatchesReference((bytes32,string)[]) (runs: 8161, μ: 59888, ~: 42418)
It passes at the repo's configured 2048 runs, so this is not currently red. The point is the margin: the budget is a flat 65536 rejections regardless of run count, so at 2048 runs the test can afford ~32 rejections per accepted input and at 8192 only ~8. It is sitting inside a factor of four of its ceiling.
The three vm.assume calls it stacks are
vm.assume(authoringMeta.length > 0);
vm.assume(authoringMeta.length <= 0x20);
vm.assume(!LibBloom.bloomFindsDupes(LibAuthoringMeta.copyWordsFromAuthoringMeta(authoringMeta)));
and the length bounds are the expensive pair: a uniformly fuzzed dynamic array is rejected whenever its length falls outside [1, 32], which is most draws. Two sibling tests in the same file stack the same bounds.
This is independent of #145 — that PR did not touch this file, and the rejection pressure here is the length bounds rather than a fingerprint collision. Filing it separately so the two are not conflated.
Worth noting as the reason it matters: anything that raises the rejection rate on these tests, or any future bump to [fuzz] runs, turns this from a thin margin into a red CI leg whose message (rejected too many inputs) points at the harness rather than at whatever actually changed.
🤖 Generated with Claude Code
LibGenParseMetaFindExpanderTest.testFindExpanderMatchesReferenceexhausts itsvm.assumebudget before finishing when run at more than the configured number of fuzz runs.It passes at the repo's configured 2048 runs, so this is not currently red. The point is the margin: the budget is a flat 65536 rejections regardless of run count, so at 2048 runs the test can afford ~32 rejections per accepted input and at 8192 only ~8. It is sitting inside a factor of four of its ceiling.
The three
vm.assumecalls it stacks areand the length bounds are the expensive pair: a uniformly fuzzed dynamic array is rejected whenever its length falls outside
[1, 32], which is most draws. Two sibling tests in the same file stack the same bounds.This is independent of #145 — that PR did not touch this file, and the rejection pressure here is the length bounds rather than a fingerprint collision. Filing it separately so the two are not conflated.
Worth noting as the reason it matters: anything that raises the rejection rate on these tests, or any future bump to
[fuzz] runs, turns this from a thin margin into a red CI leg whose message (rejected too many inputs) points at the harness rather than at whatever actually changed.🤖 Generated with Claude Code