-
|
I'm hitting some unexpected behavior (but maybe it's intended?) when trying to get details on specific token ids for erc 721 contracts. E.g., https://explorer.celo.org/mainnet/token/0x563BfCD6641798cD5B071DF43BfAC2e7e48F12e2/token-transfers and visiting a token id details from that page (like https://explorer.celo.org/mainnet/token/0x563bfcd6641798cd5b071df43bfac2e7e48f12e2/instance/2) 404s. Is this expected? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
Unfortunately this issue was discovered in February and represents a failure of the application to fetch nft metadata in a performant way. We believe there is a solution for the issue upstream. |
Beta Was this translation helpful? Give feedback.
-
|
After having a closer look into that particular issue it turns out that:
Notice the only difference between the two is 1 vs 2 at the end of the URL. Both are invalid ipfs CIDs though:
To sum it up: technically speaking it turns out that it's not a bug on blockscout side (although it seemingly looks like it), but rather invalid data provided by the contract which makes it impossible to fetch the metadata and in turn display the NFT content. On the other hand fixes in the upstream will allow us to retry such cases if the contract maintainer fixes the URLs (right now blockscout won't retry them which is part of the issue that @rkachowski mentioned). |
Beta Was this translation helpful? Give feedback.
After having a closer look into that particular issue it turns out that:
tokenURI(1)for that contract returnsipfs://QmUmvYubscf86RhDKHHLxV8w7HoxAYgNDsyy9afpqBnnVe1tokenURI(2)returnsipfs://QmUmvYubscf86RhDKHHLxV8w7HoxAYgNDsyy9afpqBnnVe2Notice the only difference between the two is 1 vs 2 at the end of the URL. Both are invalid ipfs CIDs though:
To sum it up: technically speaking it turns out that it's not a bug on blockscout side (although it seemingly looks like it), but rather invalid data provided by the contract which m…