Code Quality: Implement specific error handling for jAI search API endpoint

[babblebey]

Problem

The jAI search API endpoint (src/pages/api/jai/search.js) currently uses a generic error handler that returns basic error information for all failures. This makes it difficult for users and developers to understand the cause of errors and respond appropriately.

Current Behavior

• All errors are caught and returned as a generic error message with status 500 (or e.status if present).
• No distinction between validation errors, network errors, rate limiting, or other specific scenarios.

Expected Behavior

• The API should distinguish between different error types and return specific, user-friendly messages and appropriate HTTP status codes.
• Should handle:
  • Validation errors (400)
  • Network/service errors (503)
  • Rate limiting (429)
  • Generic server errors (500)

Location

File: src/pages/api/jai/search.js

Proposed Implementation

catch (e) {
  console.error('jAI Search API Error:', e);
  // Handle different types of errors
  if (e.name === 'ValidationError') {
    return Response.json(
      { error: 'Invalid request parameters', details: e.message },
      { status: 400, headers: corsHeaders }
    );
  }
  if (e.name === 'NetworkError' || e.code === 'ENOTFOUND') {
    return Response.json(
      { error: 'External service unavailable', details: 'AI service is temporarily unavailable' },
      { status: 503, headers: corsHeaders }
    );
  }
  if (e.status === 429) {
    return Response.json(
      { error: 'Rate limit exceeded', details: 'Too many requests. Please try again later.' },
      { status: 429, headers: corsHeaders }
    );
  }
  // Generic server error
  return Response.json(
    { error: 'Internal server error', details: process.env.NODE_ENV === 'development' ? e.message : 'Something went wrong' },
    { status: e.status ?? 500, headers: corsHeaders }
  );
}

Steps to Complete

1. Update catch block to handle specific error types.
2. Return 400 for validation errors, 503 for network/service errors, 429 for rate limiting, 500 for generic errors.
3. Test each error scenario.

Definition of Done

• [ ] Error handler distinguishes between error types.
• [ ] Each error returns a specific status code and message.
• [ ] CORS headers are included in all error responses.
• [ ] Existing functionality for successful requests remains intact.

[Malay-dev]

Hey @babblebey, I would like to work on this improvement. Please assign this to me. 😃

[mustafa-sayyed]

Hey @babblebey , I want to work on this, Please assign it to me

[babblebey]

Hey @mustafa-sayyed

Thanks for your interest, I'd assign this to you but we've seen that it might somewhat conflict the expected work from @1sh-repalto in #218

So, I'd wait for the work to be concluded before starting this.

I might hold this down for you (can't promise though) but kindly look through the project for other ones you can work on.