[Rust-Axum][Breaking Change] Implement a customizable error handler

[Victoria-Casasampere-BeeTheData]

This PR implements a way to handle errors that are not handled in the API implementations with the creation of a new ErrorHandler trait. This is beneficial for dealing with unknown possible errors, as well as dealing with the repetitive code that comes from manually handling recurring errors between multiple different endpoints.

The breaking changes are unlikely that they will affect people in a regressive way.
These are:

• The server implementation struct now must be Send + Sync + 'static
• The server implementation must implement the trait openapi_generated::apis::ErrorHandler
• All API methods now take references instead of ownership of all parameters.

The default implementation sets the error type to () / unit, this makes users migrating to the newer version to only be required to add the line impl openapi_generated::apis::ErrorHandler for ServerImpl {} and migrate every API method to take references in all the parameters (something their LSP can very likely do) to complete the migration.

The error handler itself defaults to logging the returned error with its Debug implementation on the error log level. Users that wish to use their own error type only need to change the Result::Err return type of the methods in the API traits implementations, as well as specify the same error type as the generic type of the ErrorHandler trait being implemented in the server implementation.

// As an example
#[derive(Debug)] // Debug trait required.
pub struct CustomError;

#[derive(Debug, Clone)]
pub struct Api;

// Intended way to implement the trait for custom handling.
#[async_trait::async_trait] // Macro only needed if you define your own `handle_error()`
impl openapi_generated::apis::ErrorHandler<crate::CustomError> for Api {
    // A default implementation for this method exists, so defining it is not a requirement.
    async fn handle_error(
        &self,
        _method: &::http::Method,
        _host: &axum::extract::Host,
        _cookies: &axum_extra::extract::CookieJar,
        _error: crate::CustomError
    ) -> Result<axum::response::Response, http::StatusCode> {
        unimplemented!();
    }
}

// Alternative 1: "No need for error handling"
impl openapi_generated::apis::ErrorHandler for Api {}

// Alternative 2: "The default implementation is good enough, I just want my own error type"
impl openapi_generated::apis::ErrorHandler<crate::CustomError> for Api {}

#[async_trait::async_trait]
impl openapi_generated::apis::default::Api<crate::CustomError> for Api {
    // Now all parameters are references instead of owned values.
    async fn endpoint_v1(
        &self,
        _method: &::http::Method,
        _host: &axum::extract::Host,
        _cookies: &axum_extra::extract::CookieJar,
    ) -> Result<EndpointV1Response, crate::CustomError> {
        unimplemented!();
    }
}

# Command used to update the samples
mvn clean &&
./bin/generate-samples.sh bin/configs/manual/rust-axum-* &&
mvn integration-test -f samples/server/petstore/rust-axum/pom.xml

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request, and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in Git BASH)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples, as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@wing328 @linxGnu

[tanadeau]

Can this get added to the 7.12.0 milestone? I'd love to use this.

[linxGnu]

@Victoria-Casasampere-BeeTheData
Thank you so much for making the PR. And I am sorry for late reply due to lunar new year.

I have one concern here:

• How could user really handle the Error without some useful information (e.g URL Path, URL Params, Claims (to know who did this), etc)?

In this way, it would be the best if could include those info to ErrorHandler trait

[Victoria-Casasampere-BeeTheData]

How could user really handle the Error without some useful information.

This is not something that I needed available on my use case, so did not consider it, but I can see how having that information can be useful. I will add some additional arguments with that information to the trait method.

[Victoria-Casasampere-BeeTheData]

@linxGnu The error handler now has access to the Method, Host and CookieJar, every other parameter is way too endpoint specific, and errors that depend on knowing that data should be handled on the endpoint itself rather than the global error handler. For the purposes of error logging, this information is enough, as the additional data can be logged via instrumenting by the user, and can be looked back to when an error log pops up, as they would both share the same method, host and cookies.
One thing I don't like is that the 3 parameters need to be cloned, as making them references in the API method would be a massive breaking change.
Adding the claims to the error handler would also require for the Claim type to be Clone, or passed by reference rather than moved, something users may not want, or could even have, and the complexity of adding the generic type for the claims in the error handled is beyond me.

[linxGnu]

@Victoria-Casasampere-BeeTheData
Let's improve this situation later. At the moment, I think metadata (host/cookie/method) is enough.

[Victoria-Casasampere-BeeTheData]

I think it'll be OK if we solve the issue with the metadata being cloned so it can also be present on the error handler by making the parameters references. If we upgrade to axum 0.8, the Host extractor has been moved to axum_extra, which already would require users to go through the entire API implementation updating the imports or the type being used in the method, and on that time they could easily move everything to references, and if they need the owned value, they can explicitly clone it themselves instead of the library doing it implicitly.

[Victoria-Casasampere-BeeTheData]

@linxGnu @wing328

I have decided to try out updating axum and making the API methods take references. The breaking change I stated on my previous comment is not that massive, nearly all operations work fine with the methods being references, and the most major change is the type of each parameter in each API method now being a reference. I think it works pretty well, and it preserves efficiency while adding much needed functionality. Of course, this is just my experience with my codebase, so I'd like to see someone else try this change and see if the breaking change is too much of a chore for them or not.

[linxGnu]

@Victoria-Casasampere-BeeTheData please be aware that there is another PR opening for bumping axum.
See also: #20548

Regarding this situation, it's a rule of thumb to keep your PR as small as possible: just implementing customizable error handler?

[Victoria-Casasampere-BeeTheData]

@linxGnu
I have a preference to bundle up all the eventually required breaking changes, so dealing with them is a one-time thing, rather than something that needs to be done in smaller portions multiple times, which is why I included the Axum update as part of this PR. That being said, this is just my preference, and if the project prefers to have smaller PRs, I will comply, and so I have rolled back the update in favour of doing it in a separate PR.

[linxGnu]

LGTM. Thank you for making the PR @Victoria-Casasampere-BeeTheData