feature: Add comprehensive HTTP exception classification for retry logic

[xerial]

Summary

• Import robust exception handling from airframe-http for comprehensive retry logic
• Add HttpExceptionClassifier for nuanced HTTP response classification
• Add platform-specific exception classifiers via HttpCompat (JVM/JS/Native)
• Add HttpMaxRetryException with concrete response/status access

Key Changes

• HttpExceptionClassifier: Central classification for HTTP responses and exceptions
  • 5xx: retryable (503 with extra wait for rate limiting)
  • 4xx: selective (408, 410, 429, 499 are retryable; special 400 handling)
  • 304: treated as success
• HttpCompat: Platform-specific exception handling
  • JVM: Full SSL and connection exception classification
  • JS/Native: Stub implementations (empty classifiers)
• HttpMaxRetryException: HTTP-aware max retry exception with concrete response/status
• HttpStatus.isRetryable: Expanded to include 410 (Gone) and 499 (Client Closed Request)

Test plan

• HttpExceptionClassifierTest: Tests for response and exception classification
• HttpCompatJVMTest: JVM-specific SSL and connection exception tests
• HttpMaxRetryExceptionTest: Tests for exception creation and response derivation
• All 162 HTTP tests pass

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello @xerial, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the HTTP client's resilience by introducing a sophisticated and comprehensive exception classification system for retry logic. It centralizes the decision-making process for whether an HTTP response or an underlying exception warrants a retry, adapting behavior based on HTTP status codes and various exception types. The changes also ensure platform-specific compatibility for JVM, Scala.js, and Scala Native, and provide a more informative exception when maximum retry attempts are exhausted, ultimately leading to a more robust and fault-tolerant HTTP communication layer.

Highlights

• Comprehensive Exception Classification: Introduced a robust system for classifying HTTP responses and exceptions to determine retry behavior, ported from airframe-http.
• HttpExceptionClassifier: Added a central HttpExceptionClassifier object that provides nuanced classification for HTTP status codes (e.g., 5xx are retryable, specific 4xx like 408, 410, 429, 499 are retryable, 304 is a success) and execution failures.
• Platform-Specific HTTP Compatibility (HttpCompat): Implemented platform-specific HttpCompat layers for JVM, Scala.js, and Scala Native, allowing for tailored exception handling. The JVM version includes comprehensive SSL and java.net exception classification, while JS/Native provide simpler stub implementations.
• HttpMaxRetryException: Created a new exception type, HttpMaxRetryException, which is thrown when an HTTP request exceeds its maximum retry count. This exception provides direct access to the final HttpResponse and HttpStatus without optional types, simplifying error handling.
• Expanded Retryable Status Codes: The HttpStatus.isRetryable method has been updated to include 410 Gone and 499 Client Closed Request as retryable status codes, enhancing the client's ability to recover from transient issues.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a comprehensive and robust exception classification mechanism for HTTP client retry logic, largely ported from airframe-http. The changes are well-structured, with a central HttpExceptionClassifier, platform-specific implementations via HttpCompat, and a new HttpMaxRetryException for better error handling. The code is clean, and the addition of extensive tests is commendable. My review found one minor issue regarding redundant code in the JVM-specific exception classifier. Overall, this is an excellent improvement to the library's resilience.

[gemini-code-assist]

The case _: ConnectException within this match block is redundant. ConnectException is already handled by a more specific case on line 54. Since java.net.ConnectException extends java.net.SocketException, any ConnectException will be matched by case e: ConnectException before reaching this case e: SocketException block, making the inner case for ConnectException unreachable dead code. Removing it will improve code clarity and maintainability.

      e match
        case _: BindException =>
          retryableFailure(e)
        case _: NoRouteToHostException =>
          retryableFailure(e)
        case _: PortUnreachableException =>
          retryableFailure(e)
        case se if se.getMessage == "Socket closed" =>
          retryableFailure(e)
        case _ =>
          nonRetryableFailure(e)