fix: bedrock throttling exception on maintainers processing [CM-740]

[mbani01]

This pull request improves the robustness of the invoke_bedrock function by adding retry logic to handle throttling errors from the Amazon Bedrock API. It introduces exponential backoff with jitter for retries and cleans up error handling to avoid redundant exception logging.

Error handling and reliability improvements:

• Added retry logic with exponential backoff and jitter for handling ThrottlingException errors when calling the Bedrock API, allowing up to 5 retries with increasing delays. [1] [2] [3]
• Removed redundant generic exception handling at the end of the function, relying on more targeted error handling and logging.

Dependency and import updates:

• Imported asyncio, random, and ClientError to support the new retry and delay logic.

---

Note

Medium Risk
Adds retry/backoff and new sleep delays around Bedrock model invocation, which can change latency and failure behavior for maintainer processing if errors are misclassified or retries exhaust.

Overview
Improves invoke_bedrock robustness by retrying bedrock_client.invoke_model on AWS ThrottlingException up to 5 times using exponential backoff with jitter, logging a warning and delaying between attempts.

Refactors response parsing/validation to run after the retry loop and adjusts error logging to focus on JSON parse failures (logging the raw model text) rather than a generic “Bedrock API error” message.

^{Written by Cursor Bugbot for commit 49f2b90. This will update automatically on new commits. Configure here.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Copilot]

Pull request overview

This PR improves robustness of the Bedrock invocation path used by maintainer processing by adding explicit retry/backoff behavior for Bedrock throttling, and simplifying error handling around response parsing/validation.

Changes:

• Add throttling retry loop with exponential backoff + jitter around bedrock_client.invoke_model.
• Introduce module-level retry/backoff constants and new imports to support retry sleep and jitter.
• Restructure response parsing/validation error handling and logging.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

raise e resets the traceback and makes debugging harder. Use a bare raise here so the original exception context is preserved.

Suggested change

	raise e
	raise

[Copilot]

The outer except Exception will also catch ValidationError raised from the validation block and log it as a JSON parsing failure (and potentially log raw model text). Consider narrowing this handler to JSON/KeyError-related failures (or adding a dedicated except ValidationError: raise) so validation errors aren’t misclassified.

[Copilot]

This adds a custom retry loop on throttling, but the client Config already enables botocore retries (retries={"max_attempts": 3}), which can compound the total number of attempts and overall wait time. Consider consolidating retry behavior (either rely on botocore retries, or reduce/disable them when using this explicit backoff loop) to keep worst-case latency bounded and predictable.

[Copilot]

The except block logs response_body["content"][0]["text"], but response_body may be undefined if JSON decoding fails (or if response["body"].read()/json.loads(...) raises). This can mask the original error with an UnboundLocalError. Consider initializing response_body/raw text to a safe default and logging body_bytes (decoded) when available, or using logger.exception without indexing into response_body in the failure path.

[Copilot]

raise ve resets the traceback/context. If the goal is just to rethrow after logging, use a bare raise to preserve the original stack trace.