show crates.io search errors to the user without logging them

[syphar]

We are using the crates.io search API to power our own crate-search.

Sometimes the crates.io API returns 4xx or 5xx errors because of wrong queries or timeouts.

These errors can be shown to the user, but there is no need to report them to sentry or log them as errors.

We could add a new metric to track the amount of errors.

[syphar]

instructions:

• web::releases::get_search_results fetches the search results, it's used in web::releases::search_handler
• our logging config would send everything that is logged with tracing::error! to sentry, and also every server error
• so either the handler or the method have to be changed so we don't generate a server error any more, but just a warning.

[byfnoel]

@rustbot claim

[byfnoel]

cc: @syphar, @GuillaumeGomez

After a second take, I believe the ? bubble up errors that eventually convert to AxumNope::InternalError, which reports to Sentry and also logs as errors.

I was thinking of creating a custom error response based on how it is constructed in registry_api.rs.
See:

if let Some(errors) = response.errors {

           let messages: Vec<_> = errors.into_iter().map(|e| e.detail).collect();

           bail!("got error from crates.io: {}", messages.join("\n"));

       }

My propose solution (This goes inside src/web/releases.rs):

        match get_search_results(&mut conn, &registry, query_params).await {  
            Ok(result) => result,  
            Err(error) => { 
                // if we get an error from crates.io search api
                if error.to_string().contains("got error from crates.io:") {  
                    // Create a custom error response. Note: This would not report to Sentry 
                    
                    };  
                    return Ok(custom_error.into_response());  
                }  
                // For other errors, propagate as usual  
                return Err(AxumNope::InternalError(error));  
            }  
        }  

[syphar]

@byfnoel thank you for working on this!

generally: differentating between error types should never be done via text matching.

The cleanest way would be to introduce a new error type (enum with thiserror), that is returned by get_search_result which would enable us to differentiate between a crates.io-error and the other errors. Then you could also have the crates.io error variant contain a nice error message with whatever is coming from the crates.io API.