Enhance parse_response Method to Improve Error Handling and Logging

[armando-rodriguez-cko]

Description

This pull request introduces significant improvements and fixes to the Checkout Ruby SDK, focusing on error handling, response parsing, and code readability.

Key Changes

1. Refactored Method Definitions:

   • Streamlined method signatures to use a single-line format for better readability.

2. Enhanced Error Handling:

   • Updated CheckoutApiException to include detailed error messages and structured error details.
   • Improved parse_error_details to gracefully handle invalid JSON and added robust logging for unexpected exceptions.

3. Improved Response Parsing:

   • Added parse_body to manage responses based on their content type (JSON, CSV, or plain text).
   • Simplified parse_response logic to handle various response formats and edge cases effectively.

4. Added Comprehensive Tests:

   • New test cases in api_client_spec.rb cover:
     • Valid and invalid JSON responses.
     • Error responses with 4xx and 5xx status codes.
     • Parsing of response metadata and body content.

5. New Klarna Payment Context Handling:

   • Integrated create_payment_contexts_klarna in the helper for better Klarna-related test coverage.

6. General Improvements:

   • Refactored headers management for consistency.
   • Updated build_multipart_request to improve parameter formatting and consistency.
   • Cleaned up test files, including contexts_integration_spec.rb and reports_integration_spec.rb.

Motivation

This PR addresses an identified issue where error responses (HTTP status code > 400) were not logged, creating challenges for debugging. It aims to enhance the SDK's robustness, improve error visibility, and make the code more maintainable.

User Feedback

"We have been noticing an issue for a while, where Checkout Ruby SDK does not log response information when there is an error in a request (status code > 400). Are there any plans to improve the SDK to add this functionality? Maybe that is intended for some reason? We are reviewing whether we should implement our own custom handling for such scenarios."

This PR directly responds to the above feedback by addressing logging and error handling gaps.

Testing

• Unit Tests:

  • Added new test cases for different response scenarios in api_client_spec.rb.
  • Covered scenarios including:
    • Valid JSON responses.
    • Empty or nil response bodies.
    • Error responses with various HTTP status codes.

• Integration Tests:

  • Enhanced tests in contexts_integration_spec.rb and reports_integration_spec.rb to validate changes in response handling and error logging.