Skip to content

Comments

feat: add timeouts, retry logic, and improved error handling#81

Closed
whereisfarukk wants to merge 0 commit intovlm-run:mainfrom
whereisfarukk:main
Closed

feat: add timeouts, retry logic, and improved error handling#81
whereisfarukk wants to merge 0 commit intovlm-run:mainfrom
whereisfarukk:main

Conversation

@whereisfarukk
Copy link
Collaborator

Timeouts for chat completions (4 minutes)
Retry logic with exponential backoff for network errors
Centralized error handling

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @whereisfarukk, I'm Gemini Code Assist1! 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 improves the resilience and stability of the VlmRunClient by introducing comprehensive error management. It incorporates dynamic timeouts for API requests, including an extended duration for chat completions, and implements a robust retry strategy with exponential backoff to gracefully handle transient network issues. Furthermore, error processing has been centralized into a new utility method, ensuring consistent and informative error reporting throughout the client.

Highlights

  • Timeouts: Implemented dynamic timeouts for API requests, with a specific 4-minute timeout for chat completions.
  • Retry Logic: Added retry mechanism with exponential backoff for transient network errors (e.g., ETIMEDOUT, ECONNRESET, EPIPE).
  • Centralized Error Handling: Introduced a dedicated handleRequestError method to standardize error processing and reporting across API calls.

🧠 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.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces valuable improvements by adding timeouts, retry logic, and centralized error handling to the VlmRun client. The changes enhance the client's robustness. My review includes a few suggestions for improvement: correcting the retry backoff strategy to be exponential as described, simplifying a condition in the retry logic for better readability, extracting a duplicated endpoint string into a constant, and restoring important debugging logs that were removed during the error handling refactoring.

(!error.response && attempt < MAX_RETRIES); // Network errors without response

if (isRetryable && attempt < MAX_RETRIES) {
const delay = RETRY_DELAY * attempt; // Exponential backoff
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

The current implementation uses linear backoff (RETRY_DELAY * attempt), but the comment and the pull request description state it should be exponential. For a true exponential backoff, you could use something like RETRY_DELAY * Math.pow(2, attempt - 1).

Suggested change
const delay = RETRY_DELAY * attempt; // Exponential backoff
const delay = RETRY_DELAY * Math.pow(2, attempt - 1); // Exponential backoff

Comment on lines 163 to 165
} catch (error: any) {
// Extract error details similar to the original implementation
let errorDetail = error.message;
if (error.response?.body) {
try {
const errorBody =
typeof error.response.body === 'string'
? JSON.parse(error.response.body)
: error.response.body;
errorDetail = errorBody.detail || errorBody.message || error.message;
} catch {
errorDetail = error.response.body || error.message;
}
}
// Log full error details for debugging
console.error('VlmRun API Error:', {
url,
method,
status: error.response?.status,
statusText: error.response?.statusText,
body: error.response?.body,
errorDetail,
});
throw new Error(`HTTP ${error.response?.status || 'Error'}: ${errorDetail}`);
this.handleRequestError(error);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The refactoring to use handleRequestError is a good improvement for centralizing error logic. However, this change has removed the valuable console.error logging that was present in the previous implementation. This logging provided important context for debugging (like URL and method). It would be beneficial to restore this logging. A good approach would be to enhance handleRequestError to accept and log this additional context.


// Determine timeout based on endpoint
let timeout = DEFAULT_TIMEOUT;
if (endpoint === '/openai/chat/completions') {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The endpoint path '/openai/chat/completions' is hardcoded here and also in the chat.completions method on line 377. To avoid duplication and improve maintainability, it would be better to define this as a constant and reuse it in both places.

Comment on lines 222 to 226
const isRetryable =
errorCode === 'ETIMEDOUT' ||
errorCode === 'ECONNRESET' ||
errorCode === 'EPIPE' ||
(!error.response && attempt < MAX_RETRIES); // Network errors without response
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The condition attempt < MAX_RETRIES within the isRetryable check is redundant, as this is already checked in the if condition on line 228. This makes the code slightly harder to understand. It's better to keep the isRetryable flag focused only on whether the error type is retryable.

Suggested change
const isRetryable =
errorCode === 'ETIMEDOUT' ||
errorCode === 'ECONNRESET' ||
errorCode === 'EPIPE' ||
(!error.response && attempt < MAX_RETRIES); // Network errors without response
const isRetryable =
errorCode === 'ETIMEDOUT' ||
errorCode === 'ECONNRESET' ||
errorCode === 'EPIPE' ||
!error.response; // Network errors without response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant