Repository navigation
Retry GithubClient requests when the response handler throws UncheckedIOException - #12350
Open
Aditya Nikam (adityaanikam) wants to merge 1 commit into
Open
Aditya Nikam (adityaanikam) wants to merge 1 commit into
Aditya Nikam (adityaanikam) wants to merge 1 commit into
Conversation
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
Copilot started reviewing on behalf of
Aditya Nikam (adityaanikam)
September 23, 2026 21:50
View session
Author
|
@microsoft-github-policy-service agree |
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
No unresolved issues were identified that would block approval.
Review effort: Lite
Findings: None
What changed in this PR
Updates GithubClient retry handling so response-handler UncheckedIOException failures are retried, with regression coverage using a local HTTP server.
Changes:
- Catches
UncheckedIOExceptionalongsideIOException. - Adds a test verifying handler failures are retried successfully.
| File | Description |
|---|---|
| PluginsAndFeatures/azure-toolkit-for-intellij/azure-intellij-plugin-azuremcp/src/test/java/com/microsoft/azure/toolkit/intellij/azuremcp/GithubClientTest.java | Updated as part of this pull request. |
| PluginsAndFeatures/azure-toolkit-for-intellij/azure-intellij-plugin-azuremcp/src/main/java/com/microsoft/azure/toolkit/intellij/azuremcp/GithubClient.java | Updated as part of this pull request. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this implement/fix? Explain your changes.
GithubClient.executeWithRetry only caught IOException, but the response
handlers in getLatestAzureMcpRelease and downloadToFile rethrow
IOException as UncheckedIOException. When the response body could not
be parsed (for example a Jackson MismatchedInputException), the
UncheckedIOException escaped executeWithRetry and surfaced as an
uncaught exception during Azure MCP Server initialization, instead of
going through the retry logic and returning null as documented.
The catch now covers UncheckedIOException as well, so these failures are
retried with the existing backoff, logged to telemetry after the last
attempt, and reported to callers as null.
Does this close any currently open issues?
Fixes #12349
Any relevant logs, screenshots, error output, etc.?
The stack trace in the issue shows the exception escaping at
GithubClient.executeWithRetry (GithubClient.java:64) via the handler at
GithubClient.java:103.
Any other comments?
Adds GithubClientTest, which uses a local HttpServer and a handler that
throws UncheckedIOException on the first attempt. Verified in
isolation: the test errors with UncheckedIOException when the catch is
left as IOException only, and passes with this change. I could not run
the full IntelliJ Gradle build locally, so that is left to CI. This
does not change how non-200 responses from GitHub are handled.
Has this been tested?