Skip to content

Error_Handling_and_Logging

Jump to bottom
Shannon Atkinson edited this page Oct 30, 2024 · 1 revision

Error Handling and Logging

The No-Code Architects Toolkit is designed with robust error handling and logging mechanisms to ensure reliability and ease of troubleshooting. This section describes the error management strategies and logging configurations for different parts of the toolkit.

Error Handling

Each service module in the toolkit has dedicated error handling to manage and report errors effectively. Here’s how errors are handled in the major components:

1. API Endpoints

  • Validation: Each endpoint validates input parameters before processing. For instance, required fields like media_url are checked, and an error response is returned if they are missing.
  • Status Codes:
    • 200 OK: Returned if the request completes successfully without any issues.
    • 202 Accepted: Indicates that the request has been accepted and is being processed asynchronously.
    • 400 Bad Request: Returned if input validation fails (e.g., missing or invalid parameters).
    • 401 Unauthorized: Returned if the API_KEY is missing or invalid.
    • 500 Internal Server Error: Indicates an unexpected server-side error, usually logged for further analysis.
  • Example Error Response: 
    {
  "status": "error",
  "code": 400,
  "message": "Missing required parameter: media_url"
}

2. GCP and S3 Toolkits

  • Missing Credentials: If required environment variables for GCP or S3 (e.g., GCP_SA_CREDENTIALS, S3_ACCESS_KEY) are missing, the toolkit will log the issue and return a 500 Internal Server Error response.
  • Upload Errors: Errors during file upload to cloud storage (e.g., bucket not found, permission denied) are caught, logged, and a 500 error is returned with a message indicating the failure reason.

3. Transcription Service

  • File Type Validation: The transcription service verifies that the provided file type is compatible with the transcription model. Unsupported formats return a 400 Bad Request.
  • Model Errors: If a transcription model fails to process the file, the error is logged with details about the failure, and a 500 Internal Server Error is returned.

4. FFmpeg Toolkit

  • File Conversion Errors: Errors related to FFmpeg commands, such as unsupported file formats or codec issues, are captured and logged. The error message returned will provide details to help diagnose issues.
  • Syntax and Parameter Errors: If parameters (e.g., bitrate) are invalid or missing, the toolkit logs the problem and returns a 400 Bad Request.

5. Webhook Service

  • Delivery Failures: Webhook failures (e.g., network issues, invalid URL) trigger an automatic retry mechanism. After several retries, a failure is logged with details about the failed URL.
  • Error Notification: If a webhook notification fails, the error is logged along with the job ID and endpoint for easier tracking.

Logging

Logging is enabled across all service modules to capture detailed information about each task, which is essential for debugging and monitoring.

Logging Configuration

  • Log Level: By default, logging is set to INFO to capture key events. For debugging purposes, the log level can be increased to DEBUG.
  • Format: Each log entry includes a timestamp, log level, module name, and message. Example: 
    [2024-10-30 12:00:00] INFO [FFmpeg Toolkit] Video conversion started for job_id: convert_123
  • Log Outputs: Logs are typically output to the console for quick access, but they can be configured to write to a file for persistent logging.

Key Log Events

  1. Task Start and End: Each major task (e.g., file conversion, transcription) logs a start and end message with a unique job ID, making it easy to trace individual requests.
  2. Errors and Exceptions: All caught exceptions are logged with a stack trace when the log level is set to DEBUG. Critical errors are logged with the ERROR level, ensuring they stand out in the logs.
  3. Webhook Delivery Attempts: Each webhook delivery attempt is logged, along with any retries. Failure logs include the URL and error reason for diagnosis.

Example Log Entries

  • File Conversion Start: 
    [2024-10-30 12:05:01] INFO [FFmpeg Toolkit] Starting media conversion to MP3 for job_id: mp3_001
  • File Upload Failure: 
    [2024-10-30 12:05:15] ERROR [GCP Toolkit] Upload failed for job_id: upload_001, reason: Permission denied
  • Webhook Notification Failure: 
    [2024-10-30 12:06:00] WARNING [Webhook Service] Webhook delivery failed for job_id: mp3_001 to http://yourapp.com/webhook

Customizing Logging

The toolkit allows customization of logging configurations by modifying the logging.basicConfig setup in the main application file. You can:

  • Change the log level (e.g., INFO, DEBUG, ERROR).
  • Redirect logs to a file for persistent storage.
  • Customize the log format to suit your needs.

With thorough logging and error handling, the No-Code Architects Toolkit ensures clear visibility into its operations, making it easy to diagnose issues and track performance.

This file gives you a detailed overview of error handling and logging across the toolkit. Feel free to customize the logging configurations to fit your deployment environment!

Clone this wiki locally