buster/api/prds/active/api_http_status_fix.md

title	author	date	status	parent_prd	ticket
HTTP Status Code Fix	Claude	2024-04-07	Draft	project_bug_fixes_and_testing.md	BUS-1067

HTTP Status Code Fix

Parent Project

This is a sub-PRD of the Bug Fixes and Testing Improvements project. Please refer to the parent PRD for the overall project context, goals, and implementation plan.

Problem Statement

Current behavior:

• Permission denied errors return 404 instead of 403
• Version not found errors have inconsistent handling
• Error status codes differ between metrics and dashboards
• Error messages in status codes don't match handler messages
• No standardized error response format

Expected behavior:

• Permission denied returns 403 Forbidden
• Version not found returns 404 Not Found
• Consistent error handling across all asset types
• Clear mapping between handler errors and status codes
• Standardized error response format

Goals

1. Standardize HTTP status codes for asset handlers
2. Implement proper error status codes for permission and version errors
3. Create consistent error-to-status code mapping
4. Add comprehensive tests for status code verification

Non-Goals

1. Changing handler error messages
2. Adding new error types
3. Modifying success response format
4. Changing handler logic

Implementation Plan

Phase 1: Error Mapping ⏳ (In Progress)

Technical Design

// Error mapping structure
pub struct ErrorMapping {
    pub pattern: &'static str,
    pub status: StatusCode,
    pub message: &'static str,
}

// Error mappings
const ERROR_MAPPINGS: &[ErrorMapping] = &[
    ErrorMapping {
        pattern: "don't have permission",
        status: StatusCode::FORBIDDEN,
        message: "Permission denied",
    },
    ErrorMapping {
        pattern: "not found",
        status: StatusCode::NOT_FOUND,
        message: "Resource not found",
    },
    // ... more mappings
];

Implementation Steps

1. Create error mapping structure

   • Define error patterns
   • Map to status codes
   • Standardize messages
   • Testing requirements:
     • Pattern matching
     • Message formatting
     • Edge cases

2. Update metric route handler

   • Add error mapping
   • Update response format
   • Testing requirements:
     • All error types
     • Status code verification
     • Message validation

3. Update dashboard route handler

   • Add error mapping
   • Update response format
   • Testing requirements:
     • All error types
     • Status code verification
     • Message validation

Tests

Unit Tests

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_permission_denied_mapping() {
        let error = anyhow!("User doesn't have permission to access this resource");
        let result = map_error(error);
        assert_eq!(result.status(), StatusCode::FORBIDDEN);
        assert_eq!(result.message(), "Permission denied");
    }

    #[test]
    fn test_not_found_mapping() {
        let error = anyhow!("Metric not found");
        let result = map_error(error);
        assert_eq!(result.status(), StatusCode::NOT_FOUND);
        assert_eq!(result.message(), "Resource not found");
    }

    #[test]
    fn test_version_not_found_mapping() {
        let error = anyhow!("Version 123 not found");
        let result = map_error(error);
        assert_eq!(result.status(), StatusCode::NOT_FOUND);
        assert_eq!(result.message(), "Version not found");
    }

    #[test]
    fn test_unknown_error_mapping() {
        let error = anyhow!("Some unexpected error");
        let result = map_error(error);
        assert_eq!(result.status(), StatusCode::INTERNAL_SERVER_ERROR);
    }
}

Integration Tests

• Test Scenario: Permission Denied

  • Setup:
    • Create test metric
    • Create user without permissions
  • Steps:
    1. Attempt to access metric
    2. Verify response
  • Assertions:
    • Status code is 403
    • Message is "Permission denied"
  • Edge Cases:
    • Inherited permissions
    • Public resources
    • Invalid user

• Test Scenario: Resource Not Found

  • Setup:
    • Create test user
    • Generate invalid UUID
  • Steps:
    1. Attempt to access non-existent resource
    2. Verify response
  • Assertions:
    • Status code is 404
    • Message is "Resource not found"
  • Edge Cases:
    • Deleted resources
    • Case sensitivity
    • Special characters

Success Criteria

• All error mappings implemented
• Unit tests passing
• Integration tests passing
• Consistent behavior across asset types

Phase 2: Handler Updates 🔜 (Not Started)

[Similar structure to Phase 1]

Dependencies on Other Components

1. Test Infrastructure

   • Interface: TestDb for database access
   • Testing: Permission setup utilities

2. Asset Handlers

   • Interface: Error types and messages
   • Testing: Error generation scenarios

Security Considerations

• Consideration 1: Error Information Exposure

  • Risk: Detailed errors could expose system info
  • Mitigation: Standardized error messages
  • Testing: Message content validation

• Consideration 2: Permission Checks

  • Risk: Incorrect status codes bypass frontend checks
  • Mitigation: Comprehensive error mapping
  • Testing: All permission scenarios

References

• HTTP Status Code Standards
• Error Handling Guidelines
• Testing Best Practices