Foundry: VRFCoordinatorV2_5Mock fundSubscription reverts 0x1f6a65b6 InvalidSubscription because the blockhash-derived subId differs between simulation and broadcast

Symptom: a Foundry deploy script that creates and funds a Chainlink VRF v2.5 mock subscription in one broadcast fails on the funding call against Anvil:

vm.startBroadcast(ANVIL_DEFAULT_ACCOUNT); VRFCoordinatorV2_5Mock vrfCoordinator = new VRFCoordinatorV2_5Mock(...); uint256 subId = vrfCoordinator.createSubscription(); vrfCoordinator.fundSubscription(subId, 100 ether); // reverts vm.stopBroadcast();

The revert carries custom error selector 0x1f6a65b6, i.e. InvalidSubscription(). Deployment itself succeeds and the failing hash is visible in broadcast/.../run-latest.json.

Cause: createSubscription derives the subscription id from blockhash, among other inputs. forge script simulates the whole script first and then replays the transactions on chain, so the block context differs between the two phases. The id returned to the script during simulation is not the id stored on chain after broadcast, and fundSubscription is broadcast with the simulated value — an id that does not exist in storage. Nothing about the code is wrong; the return value simply cannot be trusted across the simulate/broadcast boundary for any value derived from block context.

Fix: split the flow and read the id back from chain state instead of from the return value.

1. One script deploys the mock and calls createSubscription(), logging the coordinator address. 2. A second FundSubscription script takes that address and obtains the id via getActiveSubscriptionIds(0, 1) — startIndex = 0, maxCount = 1 returns the only subscription on a freshly deployed mock — then calls fundSubscription.

Generalise it: inside a broadcast script, never carry a value derived from block.* or blockhash from one broadcast transaction into the next. Re-read it from the contract. The same class of bug bites CREATE2 salts and nonce-dependent addresses computed in-script.

Source: adapted from a Stack Exchange answer by SYED ASAD KAZMI (question by Harshana), https://ethereum.stackexchange.com/questions/170189/vrfcoordinatorv2-5mock-failing-to-broadcast-fundsubscription-tx-in-foundry — CC BY-SA 4.0