Daedalus doesn't show my pool for more than 10 days, SHASM server outputs URL error, but other services have no problem

hmm, it looks like the error was on 21 December, do u see any errors recently?

Everything looks ok, perhaps u should wait more time?

Cheers,

Hi @Alexd1985 ,

No, I haven’t seen any errors since then.

The error is only for two days, December 16, 2021 and December 21, 2021.

However, when the error occurred on the SMASH server on December 16, other servers, such as pool.vet, had no problem. However, five days later, the same error occurred.

So I feel that even if I wait, I will get the same error.
I wish there was some way to contact the SMASH server operator.

The following is a supplement to the checking process with the error API.

Currently, it is also puzzling that this output changes depending on the presence or absence of a trailing slash in the API for error checking.

Latest error dated December 21.

# The error for December 21, 2021 can be obtained as follows
curl -X GET https://smash.cardano-mainnet.iohk.io/api/v1/errors/383dd348581c3c16a981de1178c42f1d3134280f66bed7518b772ffd/

The URL for the meta information at this time is
https://meta.5chpool.net/5ch.json

The entire return value can be seen here.
Sorry, the status of Gist where I put the error was set to Private, so I changed it to Public.

First error dated December 16.

# The error for December 16, 2021 can be obtained as follows
curl -X GET https://smash.cardano-mainnet.iohk.io/api/v1/errors/383dd348581c3c16a981de1178c42f1d3134280f66bed7518b772ffd

The entire return value can be seen here.
The URL of the meta-information at this time is https://git.io/Ju4Ld
:exclamation: I am not currently using this URL, and now the URL https://meta.5chpool.net/5ch.json is used for the pool certificate.

it gives me error 404

Where are you hosting your metadata files?

You can’t used shorted links with git.io if it is not on github.

Additionally seems your logo is not fetched properly from extended metadata, maybe you should shorter anURL for it or make image smaller, I think there were limitation on size.

@Alexd1985 , @os11k

I am not currently using that one.
On December 16, I updated the URL in the meta-information because I thought the problem was caused by Git.io’s shortened URL, and now the URL https://meta.5chpool.net/5ch.json is used for the pool certificate.

The detailed history is as follows

1. Updated the meta-information of the pool on December 16

  • The URL of the meta-information is https://git.io/Ju4Ld
    • :exclamation: Finally, I am not currently using this URL.

2. Pool information no longer displayed on Daedalus

  • The SMASH server had a URL fetch error (error date: December 16).
    • The entire error statement can be seen here.
  • However, there is no error in pool.vet, ADAStat etc.
  • I guessed that the cause was the Git.io shortened URL.

3. Recreate the pool certificate with the new URL on December 21

4. Problem with Daedalus continues to persist

  • Even with the new URL, the SMASH server has a URL fetch error (error date: Dec 21)
    • The entire error statement can be seen here.
    • However, there is no error in pool.vet, ADAStat etc.

And here we are now.

Thanks for pointing out the image data in the extended URL.

By the way, I changed the logo today, after the error on the SMASH server, and AdaPools.org isn’t getting the logo, so I’ll fix that soon!

If you check here:

There are no metadata issues for 21st of December.

Are you sure that there are more errors after 16th of December?

@os11k

As for the error, I think I’ve shown above what I could get from IOHK’s SMASH server.

At least, I am sure that my pool is not showing up on Daedalus.
I checked it today in my Daedalus wallet. Delegaters on my pool has reported the same thing since Dec 16.

I don’t seem to see any problems with any services other than the SMASH server as you have presented.

Normally, I know from past issues that SMASH servers may take a few days to retrieve pool information.
However, it is puzzling that only this server is failing to retrieve meta information all the time while other services like this have no problem… Hmmm.

I will continue to investigate and inquire.
Thanks for your help. Please feel free to let me know if you need anything else.

Usually I check adatools for smash errors and based on my experience it works quite well for that purpose, I’m not 100% sure that there are any errors after 16th of December. I would recommend you to wait and see, I’m pretty sure in next couple of days your pool should appear in Daedalus.

And by the way, based on documentation:

https://docs.cardano.org/explore-cardano/cardano-architecture/smash-handbook

Correct way to check errors is without slash

curl https://smash.cardano-mainnet.iohk.io/api/v1/errors/383dd348581c3c16a981de1178c42f1d3134280f66bed7518b772ffd

And if you do it in correct way, without slash, you will never see any errors after 16th of December.

If you try to check errors, starting from 17th of December, you will see none:

curl https://smash.cardano-mainnet.iohk.io/api/v1/errors/383dd348581c3c16a981de1178c42f1d3134280f66bed7518b772ffd?fromDate=17.12.2021

@os11k

After several Curl retries, it seems that there are about 10 error statements that can be retrieved in one standard request.

Also, the errors seem to be displayed starting with the oldest one, unless otherwise specified.

curl -X GET https://smash.cardano-mainnet.iohk.io/api/v1/errors/383dd348581c3c16a981de1178c42f1d3134280f66bed7518b772ffd

In this case, it ends up showing 10 errors for December 16th.

curl -X GET https://smash.cardano-mainnet.iohk.io/api/v1/errors/383dd348581c3c16a981de1178c42f1d3134280f66bed7518b772ffd?fromDate=20.12.2021

In this case, you will see the error from December 21th.
If we need actual confirmation from each other for future progress, we can check with the Curl service online here.

I’ve figured out the details of the API, and I’ll make any corrections that need to be added in the posts so far.

However, the problem still remains.
As suggested, I’ll basically wait for the SMASH server to respond, but I’m curious if waiting a total of 10 days is normal compared to past information.

Hmm, interesting discovery, seems following request is just returning 10 errors and if you have newest one, it will not return. Maybe I will open an issue on Smash server github repo.

curl -X GET https://smash.cardano-mainnet.iohk.io/api/v1/errors/383dd348581c3c16a981de1178c42f1d3134280f66bed7518b772ffd

As far as there are no more errors, there are nothing else what I would think you can do. Smash server are super slow, so I would expect that your pool will show up in Daedalus quite soon.

1 Like

@os11k
Thank you for your continued support. :grinning:

I also felt that this was something that needed to be reported separately from my problem, so I was going to put up an issue on Github.

In the meantime, I’ll start working on the following

Even though it is natural that the SMASH server slows down the pace of traversal due to the large number of staking pools, the URL parsing and fetching errors seem to be a problem in themselves. At least other services are correctly parsing and fetching URLs for meta information.
That’s why we consulted here first, and we will start additional investigation by looking at the error status of other pools.

1 Like

This issue is still ongoing.

Various pooling tools show that there is no problem with the URL and hash value of our meta information, but the SMASH server does not register the metadata.

$ curl -X GET https://smash.cardano-mainnet.iohk.io/api/v1/metadata/383dd348581c3c16a981de1178c42f1d3134280f66bed7518b772ffd/8d9d155065262c372d2d6bf4ac566e3a3208df5eb4a33d0a574d644697b2623f
{"code":"DbLookupPoolMetadataHash","description":"The metadata with hash PoolMetadataHash \"8d9d155065262c372d2d6bf4ac566e3a3208df5eb4a33d0a574d644697b2623f\" for pool PoolId \"383dd348581c3c16a981de1178c42f1d3134280f66bed7518b772ffd\" is missing from the DB."}

Is it just a delay in the SMASH server’s patrol? It’s already been two weeks.
I’ve seen some URL parsing errors similar to mine in other pools, but I don’t know the cause for that.

Is there some algorithm that prevents the SMASH server from registering the pool’s hash even if the hash matching value is correct?

Is it just a delay in the SMASH server’s patrol? It’s already been two weeks.
I’ve seen some URL parsing errors similar to mine in other pools, but I don’t know the cause for that.

Is there some algorithm that prevents the SMASH server from registering the pool’s hash even if the hash matching value is correct? :thinking:


On a side note, @os11k and I have reported the oddity about the SMASH server error checking API.

Did u contacted IOHK? Perhaps they can be able to tell u what is the issue … or ask someone to check for ur pool in daedalus…

I’ve already contacted them, the first reply asked me to read the Daedalus FAQ and send them the metadata URL, so I did, but now I’m waiting for a reply.

However, it may be because of the New Year holidays, the response is taking a long time, so in the meantime we are investigating as much as we can due to requests from anxious delegates…

Thanks for your response.
I will work on this issue in coordination with IOHK for a while.


Also, if anyone else has the same symptoms as me, it would be helpful if you could write in. I've found several pools with the same error, and it would be very helpful if you could give me some information about how it was resolved over time.

U must check if all of these met the criteria:

Referring to, or pointing to metadata in the stake pool certificate is optional. The certificate might contain a URL of up to 64 bytes in length that points to a JSON object with the following content:

  • A ticker of 3-5 characters, for a compact display of stake pools in a wallet.
  • Title/name of up to 50 characters.
  • Short textual description
  • URL to a homepage with additional information about the pool (optional).

These are important considerations to note about the metadata:

  • Metadata information is encoded in UTF-8, and will never exceed 512 bytes
  • The content hash of the JSON object referenced in the URL (if present), should match the content hash in the registration certificate. If there is a mismatch, the pool will not be displayed in a wallet.
  • For the wallet to display the pool, the following conditions must be met: the registration certificate must refer to the metadata, the metadata must be valid and have the - correct content hash, and be available at the URL. It must be possible to get the metadata and validate it. If this process fails, the wallet will not show the pool.

If a stake pool operator changes the metadata, they must post a new stake pool registration certificate with the new content hash.

1 Like

Unfortunately I have no idea what to check more. keep us posted, super interested to find out where problem is.