fix(aws): extract HTTP status code from AWS SDK errors

[mfzzf]

PR 类型

• Bug 修复
• 新功能
• 文档更新
• 其他

PR 是否包含破坏性更新？

• 是
• 否

PR 描述

问题：
AWS Bedrock 渠道在调用失败时，无论上游返回什么状态码（如 400 参数错误），都会被包装成 500 Internal Server Error 返回给客户端。

修复：

• 新增 getAwsErrorStatusCode 函数，通过 smithy-go 的 HTTPStatusCode() 接口从 AWS SDK 错误中提取真实的 HTTP 状态码
• 修改 awsHandler、awsStreamHandler、handleNovaRequest 三处错误处理逻辑，使用提取到的状态码替代硬编码的 500

影响范围：
仅影响 AWS Bedrock 渠道的错误响应状态码，不影响正常请求流程。

Summary by CodeRabbit

• Bug Fixes
  • Improved AWS error handling to derive and return more accurate HTTP status codes across model invocation, streaming responses, and proxied API requests. Replaces generic internal-server-error responses so clients receive more informative status codes for AWS-related failures.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Adds a helper to extract HTTP status codes from AWS SDK errors and replaces hardcoded HTTP 500 with derived status codes in three AWS error paths (InvokeModel, InvokeModelWithResponseStream, and Nova request handling) within relay/channel/aws/relay-aws.go.

Changes

Cohort / File(s)	Change Summary
AWS error handling update relay/channel/aws/relay-aws.go	Added getAwsErrorStatusCode(err) int to derive HTTP status codes from AWS/smithy errors; replaced default http.StatusInternalServerError with the derived status in three error paths: InvokeModel, InvokeModelWithResponseStream, and Nova request handling (OpenAIError propagation).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Check getAwsErrorStatusCode() correctly identifies and extracts status codes from AWS/smithy error types.
• Verify each updated error path applies the derived status code consistently and preserves original error context.
• Confirm imports (smithy error inspection) align with the project's AWS SDK version.

Poem

🐰 I nibble bytes and chase the clues,

Errors now show clearer hues.
No blanket fives across the land,
Each response gets the code at hand.
Hooray — neat replies, from my fluffy band! 🎉

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 40.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix(aws): extract HTTP status code from AWS SDK errors' accurately summarizes the main change: adding status code extraction from AWS SDK errors.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f2e5196 and c6a8e4c.

📒 Files selected for processing (1)

• relay/channel/aws/relay-aws.go (4 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• relay/channel/aws/relay-aws.go

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between fa72a27 and f2e5196.

📒 Files selected for processing (1)

• relay/channel/aws/relay-aws.go (4 hunks)

🔇 Additional comments (4)

relay/channel/aws/relay-aws.go (4)

191-192: LGTM: Proper status code extraction for InvokeModel errors.

The error handling correctly extracts the AWS status code and propagates it to the client, resolving the issue where upstream 400/403 errors were being returned as 500.

---

218-219: LGTM: Consistent status code handling for streaming responses.

The streaming error handler follows the same pattern as the non-streaming handler, ensuring consistent status code propagation across both AWS invocation methods.

---

258-259: LGTM: Nova request error handling aligned with other handlers.

The Nova-specific handler correctly implements the same status code extraction pattern, ensuring all three AWS Bedrock invocation paths (standard, streaming, and Nova) return accurate HTTP status codes.

---

25-25: Smithy-go v1.22.5 is compatible with aws-sdk-go-v2 v1.37.2 — the import addition is appropriate.

Web verification confirms that smithy-go v1.22.5 is the correct dependency for aws-sdk-go-v2 v1.37.2. Both versions were released contemporaneously (July 2025), and aws-sdk-go-v2 v1.37.x releases explicitly depend on smithy-go v1.22.x. Later SDK releases subsequently bumped to smithy-go v1.23.0, but this version pairing is valid and well-supported.