explorer: Invalid public account address throws 500 error on TX fetch

[HDauven]

Describe the bug
When entering an invalid BLS public account address on the explorer, the balance component handles it correctly and displays "N/A", indicating the account doesn't exist or is malformed. However, the transaction retrieval still proceeds and results in a HTTP 500 error.

This happens because the frontend still attempts to fetch transactions for an invalid account.

To Reproduce

1. Open the account page on the explorer by using a malformed BLS key.
2. Observe the 500 error being propagated to the web page in the transaction overview, and the balance shown correctly as N/A.

Expected behaviour
If the input is not a valid BLS public key we should:

1. Not attempt to fetch transactions
2. Show a clear message like: "Invalid Public Account Address"

Logs/Screenshot

[nortonandreev]

Hey! Thanks for raising this issue, @HDauven.

A few observations:

• The address provided is of the expected length and is alphanumerical. However, it seems like we’re lacking sufficient client-side validation to determine if the address is actually valid before making a request to the backend.
• It would be helpful to clarify what constitutes a “malformed” address. If there are specific rules for validating a BLS public key (such as length, prefix, checksum, etc.), implementing these checks on the client-side could prevent unnecessary requests.
• As you mentioned, relying on the backend to determine if an address is valid is problematic because a 500 error is too generic. It doesn’t provide actionable feedback to the frontend or the user. It could be caused by a variety of issues unrelated to the validity of the address itself.
• Ideally, if we can establish clear validation criteria for BLS public keys, we can prevent the transaction retrieval process from being initiated for invalid keys altogether.
• Additionally, showing a clear message like: "Invalid Public Account Address" when an address fails client-side validation would enhance user experience.

Proposed Next Steps:

1. Define the validation rules for a valid BLS public key (length, format, checksum, etc.).
2. Implement client-side validation using these rules to prevent unnecessary server requests.
3. Display a clear error message if the validation fails before any backend request is made.
4. Optionally, handle backend errors more gracefully by differentiating between 500 errors caused by invalid addresses and other issues.

[ascartabelli]

4. Optionally, handle backend errors more gracefully by differentiating between 500 errors caused by invalid addresses and other issues.

Actually, I don't think that's optional; this should be the only mandatory thing: we can (and probably should) skip any client side validation entirely in this case. (cc @HDauven )

(we should keep the byte length check we already have though)

[HDauven]

4. Optionally, handle backend errors more gracefully by differentiating between 500 errors caused by invalid addresses and other issues.

Actually, I don't think that's optional; this should be the only mandatory thing: we can (and probably should) skip any client side validation entirely in this case. (cc @HDauven )

(we should keep the byte length check we already have though)

I think you're right. Looping in @herr-seppia on this

[herr-seppia]

What do you suggest?

Currently there is an error message that returns "invalid bls account" for the account/status endpoint
Why don't you simply display that message?

[HDauven]

What do you suggest?

Currently there is an error message that returns "invalid bls account" for the account/status endpoint Why don't you simply display that message?

I suggest we solve the current behavior on the explorer, because it's incomplete. How? I'll leave that up to you guys. 😄

[HDauven]

Here's an example of using an invalid address on Etherscan: https://etherscan.io/address/0x55aE3f67039c332F55bE00c1d33D989d2DA108Ci

Like @herr-seppia says, we already report this in the account/status endpoint. We can use this as a quick first win, and then do client-side validation to catch early malformed addresses and prevent unnecessary calls.

We're using Bitcoin-style Base58 for our addresses, so validating for that + byte length checks we already have can be done.

[ascartabelli]

Keep in mind that I'm answering "blindly", as in I haven't checked what the client does and what happens.

What do you suggest?

If the client asks for something like /account/:id then I would simply return a 400 if we want to be specific (otherwise I would settle for a 404), but not a 500.

My main point was simply that we don't have to introduce some client side validation other than the simple byte length one we already have.