Added exponential backoff capabilities

[pcodding]

We're seeing a number of connection issues with the Serper API that resolve themselves when retrying. Instead of requiring the agent to do this and handling it in the Runbook, we should handle it in the action.

Here's the filled-out PR template for the retry logic addition:

Description

This PR adds exponential backoff retry logic to the search_google action to handle intermittent RemoteDisconnected exceptions that occur when the Serper API connection is unexpectedly closed.

Problem: The action was experiencing indeterminate RemoteDisconnected("Remote end closed connection without response") exceptions that would resolve themselves when retrying, causing unreliable search operations.

Solution: Implemented a retry mechanism with exponential backoff (1s, 2s, 4s, 5s max) that automatically retries connection-related failures up to 3 times before failing.

Dependencies: No new dependencies required - uses existing time module and string pattern matching for error detection.

How can (was) this tested?

The retry logic can be tested by:

• Connection failure simulation: Temporarily block network access during API calls to trigger connection errors
• Normal operation: Verify that successful requests work without retry delays
• Error handling: Test with invalid API keys to ensure non-retryable errors fail immediately
• Retry behavior: Monitor logs to confirm exponential backoff timing (1s, 2s, 4s delays)

Test configuration:

• Valid Serper API key required
• Network connectivity for API calls
• Monitor action execution logs to observe retry attempts

Screenshots (if needed)

N/A - This is a backend reliability improvement without UI changes.

Checklist:

• I have bumped the version number for the Action Package / Agent
• 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 - README.md file
• I have updated the CHANGELOG.md file in correspondence with my changes
• I have added tests that prove my fix is effective or that my feature works
• OAuth2: I have made sure that action has necessary scopes (works in whitelisted mode)

Note: The retry logic is designed to be transparent to users - no changes to the action's public API or behavior, only improved reliability for connection failures.

[kariharju]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Stop retrying non-connection HTTP errors

HTTP failures from Serper (e.g., 401 for an invalid key or 400 for a bad query) are now retried up to the max_retries count because HTTPError does not hit the non-retryable branch at lines 49‑51 and only raises on the final attempt. That introduces extra delay and repeated API calls for deterministic client errors that previously failed fast and were meant to be non-retryable per the description of only handling connection drops.

Useful? React with 👍 / 👎.