test(pool-cl): testSwap's InvalidFeeForExactOut expectation was dead code

[danvaneijck]

Unblocks #2, which is red for a reason that has nothing to do with it: that PR touches a workflow file and a comment and zero Solidity, src/ identical to pinned upstream passes on it, and testSwap still reported InvalidFeeForExactOut() after 8,194 runs. The same suite passed on 2026-09-04 with a different seed.

It is not a flake. It is a hole in the test's own expectations, and it was always there.

The defect

if (zeroForOne)       { …price limit… }
else if (!zeroForOne) { …price limit… }
else if (amountSpecified <= 0 && swapFee == ONE_HUNDRED_PERCENT_FEE) {
    vm.expectRevert(CLPool.InvalidFeeForExactOut.selector);   // ← unreachable
}

The first two branches are exhaustive, so the third can never execute, for any input. The test could not arm that expectation, and therefore failed rather than passing whenever the fuzzer drew a 100% fee alongside a valid price limit and a non-negative amountSpecified.

Two more bugs were hiding behind the dead branch, and both are fixed here:

	was	is
the exactness test	amountSpecified <= 0	>= 0 — the pool reverts when the swap is not exact input, and exactInput is amountSpecified < 0. The test bounds amountSpecified to [0, int128.max], so the old condition could only ever have matched exactly zero
the fee compared	the LP fee alone, == 100%	state.swapFee — the LP fee composited with this direction's protocol fee — >= 100%, as CLPool.swap does

Rewritten to mirror CLPool.swap's own order: the price limit is checked first, the fee case second, and only one of the two can be the revert the pool actually produces.

The proof, rather than a re-run on a kinder seed

test_testSwapCoversTheHundredPercentFeeExactOutputCase replays the exact CI counterexample with no fuzzer involved. Its five Bound result logs match the CI trace exactly — 1000000, 1019, 256, 6651, 1 — so the replay is faithful, not approximate.

• against the unfixed testSwap: [FAIL: InvalidFeeForExactOut()]
• against the fixed one: [PASS]

The draw was lpFee = 1,000,000 (100%, the top of the test's own bound) with a positive amountSpecified, i.e. an exact-output swap. The pool is right to refuse it: a 100% fee consumes the whole input, so no output can be delivered.

⚠️ What I could not establish: a failure rate. The draw only reproduces under the full 75-suite run — narrowing to --match-test testSwap or even to this one suite file changes forge's per-test input stream, and 25 random seeds at 10,000 runs each produced zero failures on the unfixed code that way. So sampling says nothing here in either direction. The case rests on the structural argument above, which needs no sampling: the branch is unreachable by inspection.

Checks

• Full suite, FOUNDRY_PROFILE=ci forge test --isolate: 844 passed, 0 failed (CI's failing run was 837 passed + 1 failed)
• forge fmt --check: clean
• ✅ src/ is untouched — git diff --name-only -- src/ is empty, so upstream-guard is unaffected and the audits still describe the deployed bytecode

Upstream

⚠️ This defect is upstream's, not ours — test/ is not covered by the byte-identical rule, which is the only reason it can be fixed here. It is worth reporting to PancakeSwap so the next pin move does not reintroduce it. Not filed yet.

🤖 Generated with Claude Code