OpenAPITools / OpenAPITools/openapi-generator
[REQ] [rust-server] Log ApiError instead of discarding it
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 26.8k
- Forks
- 7.7k
- PR merge metrics
- PR metrics pending
Description
Is your feature request related to a problem? Please describe.
As far as I understood swagger::ApiError from its description, it should be returned for non-user interfacing errors.
When it is returned from the API, an internal server error is displayed to the user automatically, which I think works as intended.
But I also expected the error to be logged for the developer/administrator to investigate the problem.
Describe the solution you'd like
I think it would be good to log the error.
In my local fork, I've changed
to
Err(e) => {
// Application code returned an error. This should not happen, as the implementation should
// return a valid response.
error!("{}",e);
*response.status_mut() = StatusCode::INTERNAL_SERVER_ERROR;
and of course added a import for log::error.
Is this in line with the expectations of the maintainers, and should I open a PR with the changes?
Or is it working as intended and ApiError should be discarded?
Then I'd explain that somewhere or document this behavior.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with modules/openapi-generator/src/main/resources/rust-server/server-operation.mustache at the referenced error-handling block, then inspect the generated rust-server imports and logging setup. Confirm whether ApiError should be logged before the internal-server-error response; done means the intended behavior is implemented or documented, with the existing response behavior preserved.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100