'Allocate: account already in use' behind 'custom program error: 0x0' — the account already exists on this cluster

Symptom: anchor test --skip-build --skip-deploy against devnet passes on the first run, then on later runs prints SendTransactionError: Transaction simulation failed: Error processing Instruction 0: custom program error: 0x0 while the mocha assertions still show as passing.

How to decode it: custom program error: 0x<n> is program-specific, so the number alone is meaningless — read the innermost failing program in the log stack. Here the logs contain

Program 11111111111111111111111111111111 invoke [2]
Allocate: account Address { address: B1PePs..., base: None } already in use
Program 11111111111111111111111111111111 failed: custom program error: 0x0

Program id 11111... is the System Program, and its error 0x0 is AccountAlreadyInUse. Anchor's init constraint CPIs into create_account, which fails because the PDA (or generated keypair account) was created by an earlier run and still exists. Local anchor test normally hides this by wiping the ledger each run; with --skip-deploy, --skip-local-validator, or a devnet/mainnet provider, state persists.

Fixes, by intent: derive PDAs with a per-run seed (a random or incrementing id) so each test creates a fresh account; use init_if_needed when re-initialization is acceptable, and validate the existing state; close accounts in an after() hook; or run against a freshly reset local validator. If the test deliberately asserts that re-initialization fails, wrap it and assert on the error instead of console.log-ing it — the noisy stack in the middle of a passing suite is what makes this look like a real failure.

Applies to Anchor 0.29-0.32 with @solana/web3.js 1.x.

Source: adapted from a Stack Exchange answer by chalda (question by Mark), https://solana.stackexchange.com/questions/14176/anchor-test-has-transaction-simulation-failed-error-processing-instruction-0-c — CC BY-SA 4.0