Error handling and logging

[johnwroge]

Closes #828

What changes did you make?

Responses currently include information helpful for debugging and will need to be replaced before the app is used in production.

1. Implemented a centralized logger for the backend using python json logger:
   • Set debug level logs for QA and Dev environments
   • Set error level logs for Production environment
2. Enhanced exception handling:
   • Added logging to exceptions for improved debugging across all environments
   • Updated standard error exceptions to use specific error codes
3. Frontend updates:
   • Modified to expect and display detailed errors during signin/signup
4. Backend improvements:
   • Updated signup endpoint to check for existing users
   • Added /resend_confirmation_code endpoint needed in Convert/Port Flask code to FastAPI #789
   • Enhanced create and delete database functions to raise errors when operations fail
5. Documentation:
   • Updated README with startup and testing instructions

New Error Code Structure:

Implemented a standardized error code system for authentication-related issues:

AUTH_ERROR_CODES = {
    "AUTH001": {
        "status_code": 401,
        "message": "You may have entered an invalid email or password",
    },
    "AUTH002": {
        "status_code": 404,
        "message": "User not found",
    },
    "AUTH003": {
        "status_code": 400,
        "message": "Please verify your email first",
    },
    "AUTH004": {
        "status_code": 500,
        "message": "Error processing password change request",
    },
    "AUTH005": {
        "status_code": 404,
        "message": "User not found in database",
    },
    "AUTH006": {
        "status_code": 500,
        "message": "Error retrieving user information",
    },
    "AUTH007": {
        "status_code": 500,
        "message": "Invalid authentication response",
    },
    "AUTH999": {
        "status_code": 500,
        "message": "An unexpected authentication error occurred",
    }
}

Rationale:

Logging errors in production is crucial for maintaining the health and security of an application. The team has run into many authentication errors and the logging is meant to reduce debugging complexity in different environments.

Python json logger was used over the standard root logger for these reasons.

1. Limited control over log handling, potentially leading to unexpected message destinations and incorrect log levels.

2. Difficult management of multiple loggers in complex applications, risking message duplication and misconfiguration.

3. Challenges in separating log data by module or component, hindering effective log analysis.

4. Potential security risks due to the root logger being modifiable by any module in the application.

Logging was centralized for these reasons:

1. Ensures consistent and efficient logging management as the application grows in complexity.

2. Allows customization of logging settings based on deployment environment (e.g., more verbose in development, more concise in production).

3. Improves code readability and maintainability by configuring logging at the application level rather than in individual modules.

4. Facilitates easier troubleshooting by providing a unified approach to handling log messages across the entire application.

5. Simplifies the process of adjusting logging behavior application-wide without modifying multiple files.

Source from Betterstack

Testing done for these changes

Frontend tests were run locally where they passed (vitest + cypress).
Backend tests were run locally where they passed (pytest).

Backend tests were updated to include new error codes used in the auth controller file.

What did you learn or can share that is new?(optional)

FastAPI's standard error format uses these formats.

1. For HTTPException:

{
    "detail": {
        "message": "Error description",
        "code": "optional_error_code"
    }
}

2. For Validation Errors (Pydantic):

{
    "detail": [
        {
            "loc": ["body", "field_name"],
            "msg": "Error message",
            "type": "value_error.type"
        }
    ]
}

I also learned about different logging levels:

1. DEBUG: Detailed information, typically useful only when diagnosing problems.

2. INFO: Confirmation that things are working as expected.

3. WARNING: An indication that something unexpected happened, or indicative of some problem in the near future (e.g., 'disk space low').

4. ERROR: Due to a more serious problem, the software has not been able to perform some function.

5. CRITICAL: A serious error, indicating that the program itself may be unable to continue running.

Source from Stack Overflow

[tylerthome]

This looks great! Good to merge by me, @erikguntner @paulespinosa let me know if anything needs a second look here

[tylerthome]

I like this implementation a lot. One question for us is whether we'd prefer to offload this configuration to the .env or similar env-specific config file instead of in the code

[paulespinosa]

Nice! Thank you!