Skip to content

fix: added error handling for connection issues #56

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

ronnakamoto
Copy link

@ronnakamoto ronnakamoto commented May 16, 2025

This PR addresses issue #11 by improving the error handling for connection issues in the CLI.

Added:

  1. Added a custom error type CliError to handle connection errors more gracefully
  2. Improved error messages for common connection issues:
    • DNS resolution failures
    • Connection refused errors
    • Connection timeouts
    • Protocol mismatches (HTTP vs HTTPS)
    • Invalid URL formats
    • Invalid IP addresses
    • Connection closed/reset errors
  3. Added helpful suggestions for users when connection errors occur
  4. Added automatic handling of URLs without the http:// protocol prefix
  5. Improved the command-line help text to indicate that the protocol is optional

Example DNS Issue:

Unable to connect: DNS resolution failed

Could not resolve the host name: nonexistenthost.example.com

Please check that:
  1. The hostname part of the URL is correct
  2. Your network connection is working
  3. DNS resolution is functioning properly

Connection Refused:

Unable to connect: Connection refused

Could not connect to Thunder node at http://127.0.0.1:9999/

Please check that:
  1. The Thunder node is running
  2. The RPC server is enabled
  3. The RPC address is correct (http://127.0.0.1:9999/)
  4. There are no firewall rules blocking the connection

Connection Timeout:

Unable to connect: Connection timed out

The connection to http://8.8.8.8:9999/ timed out.

This usually means:
  1. The server is not responding
  2. A firewall is blocking the connection
  3. The network path to the server is congested or down

Please check that the server is running and accessible.

match url::Url::parse(s) {
Ok(url) => Ok(url),
Err(e) => {
let error_msg = e.to_string().to_lowercase();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you match on url::ParseError instead? Matching by string value seems brittle and unnecessary


/// Custom URL parser that adds http:// prefix if missing
fn parse_url(s: &str) -> Result<url::Url, String> {
// Check if the URL already has a scheme
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the scheme must be http, then perhaps we should only be parsing a url::Host and port (u16), and adding the scheme ourselves

@@ -107,6 +362,73 @@ pub struct Cli {
#[command(subcommand)]
pub command: Command,
}

/// Custom URL parser that adds http:// prefix if missing
fn parse_url(s: &str) -> Result<url::Url, String> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this have a custom error type? Using String seems brittle and limiting

let rpc_url = self.rpc_url.clone();

// Build the client and handle connection errors
let client = builder.build(self.rpc_url.clone()).map_err(|err| {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to match on the error here?

.await
.map_err(|err| {
// Check if this is a connection error that happened during the request
if let Some(client_err) = err.downcast_ref::<jsonrpsee::core::ClientError>() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Downcasting here is very brittle. You probably want to match on the actual errors, so that you can display the correct error message for wrapped errors

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants