feat: Add database errors handlers to get better error messages (M2-8184)

[rcmerlo]

• Tests for the changes have been added
• Related documentation has been added / updated
• For new features, QA automation engineers have been tagged
• OSS packages added to MindLogger open source credit page

📝 Description

Add new error handlers for database error to have better error messages in logs, this will help to fix any error related to arbitrary servers. It will keep returning http 500 status error

🔗 Jira Ticket M2-8184

🪤 Peer Testing

Prepare environment:

• Create a new postgresql instance, you can use docker to run it in another port or run in another host, can't be the same instance
• Set arbitrary server point to this new postgresql instance
  python src/cli.py arbitrary add --db-uri postgresql+asyncpg://postgres:[email protected]/dev --storage-type aws --storage-secret-key fake --storage-access-key fake --storage-region us-east-1 --storage-bucket arbitrary OWNER_EMAIL --force
• Run migrations in this new arbitrary server
  alembic -c alembic_arbitrary.ini upgrade head
• Make sure everything is working
  python src/cli.py arbitrary show

To test connection refused error:

• Start API server
• Stop new postgresql instance
• Request completions endpoint, check for error sand check logs message in API server

To test wrong password error:

• Start API server and arbitrary server instance
• Change postgresql password
• Request completions endpoint, check for error sand check logs message in API server

✏️ Notes

To remove abritrary server, just call:
python src/cli.py arbitrary remove OWNER_EMAIL

[github-actions]

➡️ Preview environment failed to be destroyed

[github-actions]

❌ E2E tests failed

[farmerpaul]

Only one Pylance comment so far, code looks fine otherwise.

I'm struggling to figure out how to test this. I've tried misconfiguring the report server for an applet, but still not sure how to trigger the error. @rcmerlo would you mind filling out the 🪤 Peer Testing section from the PR description template? I know it's a little more work for you to do that, but it will help save the rest of us time during review. Thanks!

[farmerpaul]

Also, the AC states:

If there is a wrong setting in the arbitrary server, the BE is able to handle it without crashing and returns a proper error message in the logs instead of a 500 error.

But your PR description states:

It will keep returning http 500 status error

Which one is correct?

[rcmerlo]

Also, the AC states:

If there is a wrong setting in the arbitrary server, the BE is able to handle it without crashing and returns a proper error message in the logs instead of a 500 error.

But your PR description states:

It will keep returning http 500 status error

Which one is correct?

@farmerpaul I remember we commented on planning for this ticket that we should keep API returning 500 to not break FE behavior, since users can't handle this kind of error, we should only report it in logs to help support team to fix it.