- I have already set my Subscriptions for Chainlink
- Added consumer and subscription have sufficient Link as well
- No Error occurs whenever I call the requestRandomWords function
- fulfillment also updated on the chainlink subscriptions page
- But still, the fulfillRandomWords function is not executing the code
- tokenCounter is not updating its value
Chainlink Subscription Page
fulfillRandomWords(uint256 requestId, uint256[] memory randomWords)
internal
override
{
tokenCounter = tokenCounter + 1;
s_randomWords = randomWords;
s_one_r = randomWords[0];
address dogOwner = requestIdToSender[s_requestId];
string memory tokenURI = requestIdToTokenURI[s_requestId];
uint256 newItemId = tokenCounter;
checkUri = tokenURI;
//This newItemId should have to be a randomWords
_safeMint(dogOwner, newItemId);
_setTokenURI(newItemId, tokenURI);
Breed breed = Breed(s_randomWords[0] % 3);
tokenIdToBreenter code hereed[newItemId] = breed;
requestIdToTokenId[s_requestId] = newItemId;
emit FulfillEvent(tokenCounter, s_one_r, tokenURI);
//randomResult = randomNumber;
}
Hi Sulaman
Two questions I guess! One: is
fulfillRandomWords
erroring or reverting?Two, Is your
s_randomWords
state variable showing the random words passed into the callback? If that is updated then the callback is working but there may be some other issue withtokenCounter
that is not possible to diagnose.Can you also check the etherscan TX records for the VRF Coordinator calling your contract? If that has succeeded and the logs dont show errors then the callback is probably working as intended. You can access this Tx info from the history section of your VRF Subscription's URL. The screenshot you sent only shows the registered consumers and not the history of requests and events. Please check the Tx hash under History > Recent Requests and inspect for errors. The tx should record the call from an oracle providing the randomness to the VRF Coordinator (the coordinators address will show in the "To" field). If you open that Tx in etherscan and look at Internal TXs there should be one that is from the Coordinator to your smart contract (the callback) and that will also show the gas limit you set in your code etc.
If that call has no issue against it then the callback executed OK.
UPDATE 27 MAY 2022 OP posted the etherscan link which indicates (from the Internal Txns ) an "out of gas" error.