Flacky test: `max_buffers_in_one_instruction`

[fedgiac]

I've noticed the test max_buffers_in_one_instruction fails, see logs here. Retrying made it pass.
Other cases:

• https://github.com/cowprotocol/solana-programs/actions/runs/29349382798/job/87141386932
• https://github.com/cowprotocol/solana-programs/actions/runs/29517089524/job/87684717919
• https://github.com/cowprotocol/solana-programs/actions/runs/29613770471/job/87994196737

The failures seem unrelated to the PRs where they happened.

[fedgiac]

Debugged! This was a very interesting issue so I'm sharing the details here. Will fix it eventually once I've decided how.

The short version

• The test packs 30 buffers into one transaction, the most the account-lock limit allows.
• A transaction gets 200,000 compute units by default.
• Creating 30 buffers costs just under 200,000 CU, but the exact cost is a bit random each run.
• Most runs land under 200,000 and pass. Once in a while it goes beyond that and the run fails.

Where the randomness comes from

For every buffer, the program derives a PDA on-chain with find_program_address. That tries bump seeds from 255 downward, and each attempt is one create_program_address syscall costing 1,500 CU. How many attempts it takes depends on the buffer's address, which depends on the mint.

The test creates random mints (litesvm_token::CreateMint makes a fresh random keypair every call). So each run gets different canonical bumps → a different number of syscalls needed → a different total CU.

Can't we just raise the CU limit?

For doing that, we need a syscall, SetComputeUnitLimit. But doing this syscall requires an account... which we don't have, because we already use all 64 accounts that a transaction can use! Then we would be reducing the number of buffers we can create to fix this issue.

The magic numbers

Number	Meaning
200,000	Default compute units per transaction.
1,500	CU for one bump-search step in the (single) create_program_address syscall.
255	Bumps start here and count down.
64	Max accounts a transaction can lock (the higher 128 limit is feature-gated and off).
30	Max buffers by the lock limit: 4 fixed accounts + 2×30 = 64.
29	Max buffers if you also raise the budget: a SetComputeUnitLimit instruction adds the ComputeBudget program as a 5th fixed account, so 5 + 2×29 = 63 ≤ 64 (30 would be 65, over the limit).

Reproduction

How to reproduce

just build-program build-test-programs
for i in $(seq 1 500); do
  cargo test -p settlement --test create_buffer max_buffers_in_one_instruction -- --exact --nocapture 2>&1 \
    | grep -E "compute units|ComputationalBudget"
done

On my test:

• 6 / 500 runs failed (~1.2%).
• Passing runs used: min 144,269, mean (passing) ~170,631, max 199,769 CU (231 short).
• All values exactly 1,500 apart.

Possible fixes

• Give the test more budget. Let the test's LiteSVM use a bigger compute budget so 30 buffers always fit.
• Use 29 buffers. Add a SetComputeUnitLimit instruction and drop to 29. This is exactly what a real transaction would do. But most transactions would still be able to fit 30 accounts, this is an exceptional case (<2% of all runs).
• Fewer, cheaper steps. Cut the on-chain bump search (e.g. pass the bump in) so each buffer costs less and the total isn't near the limit. Biggest change; touches the program, not just the test.