fix: handle error from bedrock batch status check

[b4s36t4]

Description

Handle error from bedrock and return the error for batch output

Motivation

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)

How Has This Been Tested?

• Unit Tests
• Integration Tests
• Manual Testing

Screenshots (if applicable)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Related Issues

[matter-code-review]

Description

🔄 What Changed

• The getModelProvider function in src/providers/bedrock/getBatchOutput.ts was updated to correctly identify 'amazon' models as 'titan' providers.
• Robust error handling was implemented for the retrieveBatchesResponse in src/providers/bedrock/getBatchOutput.ts. If the Bedrock API returns a non-OK status, the response body is read as text, formatted into a standard error object, and returned to the client with the appropriate HTTP status.

🔍 Impact of the Change

• Ensures accurate model provider mapping for 'amazon' models, improving compatibility.
• Prevents unhandled exceptions and provides structured error responses when the Bedrock batch status check API fails, significantly enhancing the reliability and user experience of the batch processing flow.

📁 Total Files Changed

• src/providers/bedrock/getBatchOutput.ts: Added 'titan' provider mapping and robust error handling for Bedrock API responses.

🧪 Test Added

• No explicit tests were added in this PR.

🔒Security Vulnerabilities

• No new security vulnerabilities were introduced. The improved error handling contributes to better system reliability and prevents potential information leakage from unhandled exceptions.

Motivation

• To correctly map 'amazon' models to the 'titan' provider.
• To gracefully handle errors returned by the Bedrock batch status check API, preventing crashes and providing informative error messages.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)

How Has This Been Tested?

• Unit Tests
• Integration Tests
• Manual Testing

Screenshots (if applicable)

N/A

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Related Issues

N/A

Tip

Quality Recommendations

1. Consider using a Map or object literal for getModelProvider to improve readability and extensibility over a long if/else if chain.

2. Enhance error logging within the getBatchOutput function to capture the full error details from Bedrock for debugging purposes, rather than just returning the raw error text to the client.

3. Add unit tests for the new error handling logic in getBatchOutput to ensure it behaves as expected under various error scenarios.

Tanka Poem ♫

API call failed,
Error caught, now handled well,
Titan's strength revealed.
No more crashes, smooth the flow,
Code evolves, a steady climb. 🚀

Sequence Diagram

sequenceDiagram
    participant Client
    participant Gateway as Gateway (getBatchOutput)
    participant BedrockAPI as Bedrock API

    Note over Gateway: getModelProvider(modelId) updated to include 'amazon' -> 'titan'

    Client->>Gateway: requestBatchOutput(batchId, modelId)
    Gateway->>BedrockAPI: GET /batch/status (batchId)

    alt Bedrock API Response is NOT OK
        BedrockAPI-->>Gateway: Error Response (status, errorText)
        Gateway->>Gateway: Parse errorText into structured error
        Gateway-->>Client: Error Response (status, {error, provider: BEDROCK})
    else Bedrock API Response is OK
        BedrockAPI-->>Gateway: Success Response (batchDetails)
        Gateway->>Gateway: Extract outputFileId from batchDetails
        Gateway-->>Client: Batch Output (outputFileId)
    end

Loading

[matter-code-review]

Error handling added for bedrock batch status check. Minor improvements suggested for error structure and provider mapping.

[matter-code-review]

🔴 Security/Data Exposure

Issue: Error response includes raw error text which may expose internal details
Fix: Sanitize error message or use a generic message for production
Impact: Prevents leaking internal system details to clients

Suggested change

	const error = await retrieveBatchesResponse.text();
	const _error = {
	message: error,
	param: null,
	type: null,
	};
	const error = await retrieveBatchesResponse.text();
	const _error = {
	message: 'Batch retrieval failed',
	param: null,
	type: null,
	};

[narengogi]

please follow the exisitng format for provider errors
Bedrock error: {errorMessage}
you can use the generateErrorResponse() utility present in /providers/utils