skybridge/FAILING_TESTS_PROMPT.md

KMS API - Failing Tests Analysis & Resolution Prompt

Context

I have a Go-based Key Management Service (KMS) API with comprehensive end-to-end tests. The server is running successfully on port 8081, but several tests are failing due to database connectivity issues and some implementation gaps. I need help resolving these failing tests.

Current Test Results

Total Tests: 22
Passing: 17
Failing: 6

Failing Tests Analysis

1. Database Connectivity Issues (Primary Problem)

[FAIL] Readiness Check (Expected: 200, Got: 503)
Response: {"status":"not ready","timestamp":"2025-08-22T17:17:03Z","checks":{"database":"unhealthy: sql: database is closed"}}

[FAIL] List applications with auth (Expected: 200, Got: 500)
Response: {"error":"Internal Server Error","message":"Failed to list applications"}

[FAIL] List applications with pagination (Expected: 200, Got: 500)
Response: {"error":"Internal Server Error","message":"Failed to list applications"}

[FAIL] Create application (Expected: 201, Got: 500)
Response: {"error":"Internal Server Error","message":"Failed to create application"}

[FAIL] Missing content-type (Expected: 400, Got: 500)
Response: {"error":"Internal Server Error","message":"Failed to create application"}

Root Cause: The server logs show "sql: database is closed" errors. The PostgreSQL database is not running or not properly connected.

2. Edge Case Handling

[FAIL] Delete non-existent token (Expected: 500, Got: 204)

Issue: The delete token endpoint returns 204 (success) even for non-existent tokens, but the test expects 500 (error).

What Needs to be Completed

Priority 1: Database Setup & Connection

1. Start PostgreSQL Database

   • Either start a local PostgreSQL instance
   • Or set up Docker container with PostgreSQL
   • Or configure the application to use an in-memory/mock database for testing

2. Database Configuration

   • Verify database connection string in configuration
   • Ensure database migrations run successfully
   • Check that database tables are created properly

3. Connection Pool Management

   • Fix the "database is closed" error
   • Ensure proper database connection lifecycle management
   • Verify connection pool settings

Priority 2: Application Service Implementation

The application CRUD operations are failing, which suggests:

1. Repository Layer: Verify PostgreSQL repository implementations work correctly
2. Service Layer: Ensure application service properly handles database operations
3. Error Handling: Improve error responses for database connectivity issues

Priority 3: Token Service Edge Cases

1. Delete Token Validation: The delete token endpoint should return appropriate error codes for non-existent tokens
2. Error Response Consistency: Ensure consistent error handling across all endpoints

Technical Details

Server Configuration

• Server Port: 8081 (8080 was in use)
• Database: PostgreSQL (currently not connected)
• Framework: Gin (Go web framework)
• Architecture: Clean architecture with repositories, services, and handlers

Key Files to Examine

• cmd/server/main.go - Server startup and database initialization
• internal/database/postgres.go - Database connection management
• internal/services/application_service.go - Application CRUD operations
• internal/services/token_service.go - Token management
• docker-compose.yml - Database container configuration
• migrations/001_initial_schema.up.sql - Database schema

Current Working State

✅ Working Endpoints:

• Health check (basic)
• Authentication (login, verify, renew)
• Token operations (create, list, delete - when not requiring complex validation)
• Error handling for malformed JSON
• API documentation

❌ Failing Endpoints:

• Readiness check (database health)
• Application CRUD operations
• Some edge case validations

Success Criteria

After resolution, all 22 tests should pass:

1. Database connectivity restored (readiness check returns 200)
2. Application CRUD operations working (create, read, update, delete, list)
3. Proper error handling for edge cases
4. All endpoints returning expected HTTP status codes

How to Test

Run the E2E test script to verify fixes:

BASE_URL=http://localhost:8081 ./test/e2e_test.sh

The test script provides detailed output showing exactly which endpoints are failing and what responses they're returning versus what's expected.

Additional Context

• The server starts successfully and handles HTTP requests
• Authentication middleware is working correctly
• The issue appears to be primarily database-related
• Some service implementations may have placeholder code that needs completion
• The test suite is comprehensive and will clearly show when issues are resolved