Revisit Fleet server DB error handling.

[ghernandez345]

Goal

User story
As a fleet API developer,
I want to know when a 5xx server error occurs,
so that I can handle 500 errors appropriately.

Context

There seems to have been a decision to change all MySQL errors to validation errors with the error message Validation Failed and a 4xx status code. Sometimes, the errors are 5xx errors, like malformed SQL queries, but we lose this information when we change the status code and message. This seems to have been deliberately added in in this PR. We also expose DB implementation details in our API response messages when these errors occur, such as in this issue here

Changes

I think we should revisit how we handle DB error handling and not change the error status code or message for when actual 5xx DB errors occur. We should also ensure we don't leak DB implementation details in the error responses.

QA

Risk assessment

• Risk level: Low

Testing notes

Confirmation

1. [ ] Engineer (@____): Added comment to user story confirming successful completion of QA.
2. [ ] QA (@____): Added comment to user story confirming successful completion of QA.

[noahtalerman]

Thanks for tracking this one @ghernandez345!

Since this looks like an engineering initiated story, I'm removing :product and leaving ~engineering-initiated so that it moves into Luke's queue.

[github-actions[bot]]

This issue is stale because it has been open for 365 days with no activity. Please update the issue if it is still relevant.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[fleet-release]

Errors in the cloud, Fleet now reveals the truth, Silent no more, loud.