Error rendering node's pubkey when there's no match on tx

[pdp2121]

The error message on NoMatch transactions page should show the node's pubkey, but at the moment it shows a piece of code.

[ckniffen]

This is because clio nodes don't provide a public key with their clio response.

[sohammk08]

@pdp2121 Can you give me the link for the example that you have provided in the image?

• Also, what code section/what files do I need to check to possibly explore the solution?
• Is this something that can be solved by making changes in the explorer repository itself or does the root of this problem/issue lie in the clio repo, some other repository or elsewhere?

Please let me know if this issue is still relevant so I can give it a try.

[mvadari]

@pdp2121 Can you give me the link for the example that you have provided in the image?

You can see it on any invalid transaction hash, e.g. https://livenet.xrpl.org/transactions/E64A81D9FDE13F2FE28A98F337809D894E3279C75ED8E784114C650A04DFC65D

• Also, what code section/what files do I need to check to possibly explore the solution?
• Is this something that can be solved by making changes in the explorer repository itself or does the root of this problem/issue lie in the clio repo, some other repository or elsewhere?

This is definitely an Explorer problem. The Transactions folder should be a good place to start - you can find the error message and figure out a better error message to put in for a Clio node.

[ckniffen]

The code that has the translation is here: https://github.com/ripple/explorer/blob/staging/src/containers/Transactions/index.tsx#L26-L29
The code that makes the connection info of xrpl-client is here: https://github.com/ripple/explorer/blob/staging/src/containers/NoMatch/index.tsx#L33
The translation is here: https://github.com/ripple/explorer/blob/staging/public/locales/en-US/translations.json#L203C4-L203C23

The issue stems from connection.server.publicKey not being available so there needs to be a conditional check but I dont believe that can be done within the value for an i18n-next translation.

One option is scrapping listing the node you are connected to even though this can be helpful information when tracking down why a transaction doesnt exist. Many times it is because a node does not have that ledger.

[mvadari]

Seems like the problem might be with xrpl-client and its Clio support, then. nvm, the Clio server_info response doesn't have any pubkey info.

[sohammk08]

@ckniffen , @mvadari thanks for the input. I'll start looking around as per your input and suggestions.

[mvadari]

One option is scrapping listing the node you are connected to even though this can be helpful information when tracking down why a transaction doesnt exist. Many times it is because a node does not have that ledger.

I would still display it if it exists.

[sohammk08]

@mvadari mentioned in a later comment that "nvm, the Clio server_info response doesn't have any pubKey info." I've reached the same conclusion. Upon debugging, I saw that the publicKey is empty.

There are these fields in server:

"version": "empty",
"uptime": "server's total uptime",
"publicKey": "empty",
"networkId": "current network being used (perhaps the mainnet)",
"uri": "server's webSocket address and port number"

I tried changing the line in translations.json and, it worked:
I changed it as such:

"server_ledgers_hint": "This node {{connection.server.uptime}} only contains ledgers {{connection.ledger.validated}}",

And it correctly shows the uptime. But the pubKey just won't show up because it is empty.

I am genuinely stuck. Is there any solution to this? Or can it not be solved at all?

[mvadari]

I'd personally just leave out the public key part if it doesn't exist, or rewrite the hint to say This Clio node ... instead.

[sohammk08]

I'd personally just leave out the public key part if it doesn't exist, or rewrite the hint to say This Clio node ... instead.

Okay, will do

[sohammk08]

@ckniffen @mvadari : Made the proposed changes: #898

[VyuduInc]

Probably just a rendering slip or the value isn’t being safely passed to the view layer.

I’d be down to jump in and fix this up so the pubkey gets properly displayed... clean, readable, and actually helpful. Seems like a quick win with some polish potential.

I’ve time and momentum right now, aiming to contribute to seven or more projects over the next two weeks. Until I hear back, I’ll scope out a few more issues in your repo to warm up.

I’ve been around the blockchain space since 2017... Forbes Tech Council writer, investor, and dev. Got a soft spot for smoothing out those UX rough edges.

Here’s my work if you wanna take a look: https://vyudu-links.netlify.app/

Let me know if I can pick this one up...