-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sync NFT hash mismatch warning after a successful match in the list #364
Comments
My assumption was wrong, but analysis yielded some interesting things. First, I assumed for every NFT 3 hashes in the nft_uri_queue were matched(license|data|metadata), but that is not the purpose of that queue which is to take all nft URIs regardless of type and confirm their hashes. Therefore the original purpose of this issue is void, but I did notice that there are more items running in the batch than there are unique NFT URIs, in my test case. ![]() You can see in the screenshot there are 8 unique combinations of type, hash, and URI; but below there are 12 lookups for this one NFT. I will keep the issue open for awhile to try to understand the redundancy. 2025-03-30T20:37:50.930358Z INFO Processing batch of 7 NFT URIs |
In the previous dbg output there is a pattern to the batches. The first 7 NFT URIs are the comprehensive total of unique URIs in this wallet. The second batch of 4 is a subset of the first. Finally the last batch of 1 NFT is one that is contained in all 3 batches. It appears as if the batches aren't fully processed and there is some carry over to the next batch. This may be due to the "hash_matches" field in the database not being updated for any number of reasons, possibly query delay due to network traffic. 2 of the 4 URIs to carry over were mime_type image/png which is a large amount of data. The one URI that carried over twice was mime_type image/png. Interestingly, today I am unable to replicate the carry over issue. All 7 unique NFT URIs process in one batch. This again may point to network traffic causing the issue. 2025-03-31T18:47:36.458946Z INFO Processing batch of 7 NFT URIs |
Unable to replicate issue. System working as designed. Closing issue. |
My feeling is that once there is a successful match found in either NFT data or metadata URI list all subsequent hash matching should be bypassed for that item, for the purpose of efficiency. I believe the way Sage Wallet NFTs work is if there is at least one data/metadata match then that is enough to attempt to render the image or json, respectively. In other words, all lookups and processing is meaningless after the first match is found.
For example nft1asu7q6eqsqvnv9xw65kdddfyqw2s9ed5gdrtp303sww6nd0dgx0scfamk8 this is an image URL that was accidentally put into a metadata URI originally and was subsequently corrected with an NFT URI update.
2025-03-16T20:15:36.126628Z WARN Hash mismatch for URI https://bafybeicytpu62leaggpamu2s5vpvwcdr2h34hkjkcsy7ys7ztpl3f637f4.ipfs.nftstorage.link/gneale-san_francisco223.png (expected 38c8ac0ae8be302caa3d92de074a821138761246b06e70d35cbe816e09f292fd but found c9ab8523619f93d162f3a99517d8d1f71a1877fcc51e5e2f30bf6a468c640868)
The text was updated successfully, but these errors were encountered: