Reputation: 9
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;
}
Upvotes: 0
Views: 639
Reputation: 21
I'm running into the same issue. Randomness is generated for me but the callback to my consumer contract is failing. Please refer to this address to see the logs.
The revert error is silent because VRFCoordinatorV2
is using call
method to call rawFulfillRandomWords
which calls fulfillRandomWords
in my consumer contract. So all I'm getting is RandomWordsFulfilled
event with success: false
How can I know the reason the call of my consumer fulfillRandomWords
is failing?
I'm emitting an event in the first line of my fulfillRandomWords
but it is not being emitted. This means the callback from the coordinator is failing to call fulfillRandomWords
without even executing the first line of fulfillRandomWords
. In other words, there is nothing in my code is causing fulfillRandomWords
call to fail because its first line (event emitting) is not being executed.
Upvotes: 2
Reputation: 294
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 with tokenCounter
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.
Upvotes: 0