explorer: Improve Handling of Network Status

Summary

The current Devnet Explorer is returning errors when the connected node is down, but the status badge remains green, misleading users to think the network is operational. The user experience is suboptimal, and we need to find a better way to handle this situation. The issue extends to how the explorer handles connections with nodes and how it reflects network availability.

Context

• Problem: When the node the explorer is connected to is down, users encounter errors and the status badge remains green. This leads to confusion as users assume the network is operational while it’s actually down.
• Challenge: As Hein mentioned,

There's no real way to know if the entire network is down, only the node you're connected to

which complicates how we display the network status.

• Clarification
  • When we connect to an URL such as nodes.dusk.network, it's believed we are connecting to a specific node, typically a master "explorer node." This is done to avoid overloading the consensus nodes. If the node goes down, it’s not currently handled well by the Explorer.

Proposed Solution

1. Step-by-Step Approach:

   • Single Node Handling: Start by updating the badge to reflect when the node the explorer is connected to goes offline. Inform the user of the connection issue and introduce an empty state for blocks and transactions while keeping the explorer as functional as possible.
   • Multi-Node Setup (Future Consideration):
     • Maintain a list of nodes that the explorer can attempt to connect to.
     • If one node fails, try another. If all nodes fail, assume the network is down and notify the user appropriately.

2. Additional Considerations:

   • It's possible to get information about other nodes by querying the peers of the node we're connected to.
   • A future solution could include a more robust multi-node setup if necessary, but the initial step is to handle single-node failure more gracefully.

Additional UX Consideration

Another important UX aspect to address is that the badge indicates the network (like testnet, devnet, etc.). Changing the badge color would typically be interpreted by users as a reflection of the status of the entire network, not just the specific node. We shouldn’t assume users are aware that the explorer connects to a particular node. To clarify:

• We could use a red badge if we are certain the entire network is down.
• We could use a yellow badge (along with additional information) to indicate that we only know the current node is down or unreachable. This way, users are clearly informed about the scope of the issue (node vs. network).

Next Steps

• Implement the first step by improving how we handle single-node disconnection in the explorer.
• Consider using a color-coded badge system (yellow for node-specific issues, red for network-wide issues) to improve UX clarity.
• Later, explore a multi-node solution to further improve reliability.

This issue was raised following internal discussions on how to improve the Devnet Explorer’s handling of network connectivity issues and how the user experience could be improved in cases where the connected node becomes unresponsive.

A visual representation of the problem is shown below:

Start by tracing the explorer’s node connection handling and the network status badge, then reproduce the behavior with the connected node unavailable. The initial work is done when a node-specific outage is communicated clearly, blocks and transactions show an appropriate empty state, and the explorer remains as functional as possible without implying that the whole network is down.