Registrar #1 Display name and status incorrect

[chevdor]

Location: https://polkascan.io/pre/kusama/account/registrars
Registrar #1 shows as:

In the PolkadotJS UI it shows properly:

Beside, I would be interested in knowing where this Tester is coming from.

[chevdor]

Any news on this issue?

It is rather alarming if the UI of Polkascan does not show 100% the state of the chain and it raises the question whether some other discrepancies exist between displayed values and on-chain state.

Please note that Polkascan does see the registrar verification:
https://polkascan.io/pre/kusama/account/Fom9M5W6Kck1hNAiE2mDcZ67auUCiNTzLBUdQy4QnxHSxdn#identity

So there is a bug somewhere.

I don't recall ever using Tester anywhere so I really wonder were this value comes from.

[arjanz]

I ran some tests and locally it shows the correct identity, so not sure why it shows like that on Polkascan, we are still investigating.. Obviously we have our 'mini state-machine' that could get out of sync when events or calls change due to runtime upgrades, but this doesn't seem to be the issue in this case. We will keep you updated if this is a bug or some faulty data was unintentionally synced

[chevdor]

Any news on this issue ?

[chevdor]

I see you managed to remove the "tester" label on Registrar #1

However, display name and verification status are still missing. Did you identify the issue?

[chevdor]

Any news ?

[chevdor]

The issue or a similar one also shows up on CC1.
Some definitely verified accounts are showing a wrong status despite the judgement being visible to Polkascan.

Some examples below:

Hint, the issue seems to be showing up for judgements set thru a proxy with ProxyType = IdentityJudgement .

[chevdor]

As far as Kusama is concerned, there was a change, now no status is visible at all for Registrar #1:

[emielsebastiaan]

We are aware of those problems. This requires substantial refactoring and will be scheduled sometime in August.

[chevdor]

Can you explain what the issue is and why it affects some accounts and not some others ?

[arjanz]

It has to do with the fact that we use the data from the referenced extrinsic of the IdentitySet and JudgementGiven events to determine what the identity data is or what judgement is given. But with the introduction of batched calls and sudo calls, this mechanism gets confused because the actual data is wrapped in a Vec or positioned elsewhere in the call. You can see this as an 'internal call', sort of same idea with the internal transaction of Ethereum.

We are aware of this shortcoming, but refactoring to extract all the calls from the extrinsics in a uniform way will take some time unfortunately..

So basically, currently it should work if the call of the extrinsic is Identity.set_indentity or Indentity.provide_judgement, but not yet if the call in the extrinsic is a Utility.batch or Sudo.sudo.

[chevdor]

Thanks for the explanation, that totally makes sense, and you can probably add proxy.* calls to the list.