Description
Internal/External
External otherwise.
Summary
Pool is shown as UNKNOWN for days in delegator dashboards after metadata has been updated in a valid manner when past URLs are reused, even when URLs are used in an alternate fashion.
Steps to reproduce
Steps to reproduce the behavior:
- Change pool description in the metadata on-chain in a valid manner using URL A
- Verify Daedalus has picked up the change
- Verify adapools.org has picked up the change
- Verify pooltool.io has picked up the change
- Verify cardanoscan.io has picked up the change
- Double check pool metadata settings at pool.vet
- Download metadata file from registered URL to shell with e.g. wget and double check hash with cardano-cli
- Double check there are no SMASH API errors
- Double check SMASH server is uptodate
- Check Yoroi delegation dashboard is OK
- Change pool description again using a new URL B and repeat steps 1 to 10
- Change pool description again reusing URL A and repeat steps 1 to 10 with new hash and new description
- Notice error in Yoroi Dashboard, pool is shown as UNKNOWN POOL (On Mobile "GO TO WEBSITE" Button is broken as well) for multiple days as Yoroi detects a hash mismatch between the new file content of URL A and the for URL A stored old hash and aborts
- Re-run modification transaction with no change in data with URL A
- UNKNOWN bug is fixed within 24 hours by submitting the transaction with the old URL twice
Expected behavior
Yoroi updates valid pool metadata in the same efficient manner as other wallets and tools by refreshing with the new hash and new description with a reused alternate URL, provided this URL has not been used in the current valid registration.
Screenshots and attachments
I had this issue with STR8 pool, ID: 000006d97fd0415d2dafdbb8b782717a3d3ff32f865792b8df7ddd00. I updated the description in metadata on June 5th 17:13 UTC:
Daedalus wallets I checked were quick to update (validating metdata hash) the description on the same day within minutes, as was adapools, pooltool, and cardanoscan I checked.
Pool.vet check was ok as well:
wget https://straightpool.github.io/about/poolmeta.json
cardano-cli stake-pool metadata-hash --pool-metadata-file poolmeta.json
returned the correct hash as well 45e9013747baa8d48f392a907b0299f519e8fd4eaa7453f1fcc70780148cfbf2
There were no SMASH API errors:
https://smash.cardano-mainnet.iohk.io/api/v1/errors/000006d97fd0415d2dafdbb8b782717a3d3ff32f865792b8df7ddd00
SMASH was up-to-date:
https://smash.cardano-mainnet.iohk.io/api/v1/metadata/000006d97fd0415d2dafdbb8b782717a3d3ff32f865792b8df7ddd00/45e9013747baa8d48f392a907b0299f519e8fd4eaa7453f1fcc70780148cfbf2
Yet, Yoroi showed UNKNOWN POOL to delegators in the Dashboard (in both Desktop and Android Yoroi wallets), the delegation list fed by adapools.org is fine
Check-ins with display of UNKOWN POOL:
- Negative check on June 15th 18:11 UTC, more than 10 days
- Resubmitted transaction on June 15th 21:30 UTC
- Fixed: June 16th 06:20 UTC
Additional context
Instead of creating a new metadata file for each description change, I hosted two metadata files "poolmeta.json" and "poolmetadata.json" and alternate between those two, expecting this to work. When I switched to using "poolmeta.json" again (last use was in July 2020) it had a different description and hash from what the backend in Yoroi has seen previously.
The Yoroi backend detected a hash mismatch with the first modification run, Yoroi backend remembered the hash for the old version of URL A and expected the new file content of the old URL to match, this of course failed. The first run most likely updated the hash in the backend so after the next re-registration run the now updated stored hash for URL A matched the new file content.
As a workaround to avoid this issue with Yoroi dashboard the same URL for poolmeta data should never be re-used not even in an alternate fashion or if it is reused the modification transaction should be submitted twice in short succession.
The Yoroi backend uses a number of servers so if after the fix not all wallets show the new metadata correctly other servers shall fall in line in a few days at most as a pure caching issue remains.