Skip to content

Conversation

@LydianJay
Copy link

Added onClose and onError callbacks for customize handling these events
Added an option to reconnect on closed

@gemini-code-assist
Copy link

Summary of Changes

Hello @LydianJay, 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 enhances the SimpleFlutterReverb library by introducing flexible callback mechanisms for handling WebSocket connection closure and errors. It also adds an optional automatic reconnection feature, allowing the client to gracefully recover from dropped connections. These changes provide developers with greater control over connection lifecycle management and improve the overall resilience of the WebSocket client.

Highlights

  • Enhanced Error and Close Handling: Introduced onClose and onError callbacks within SimpleFlutterReverbOptions to allow custom handling of WebSocket connection closure and errors, providing greater control over the connection lifecycle.
  • Automatic Reconnection Mechanism: Implemented an optional automatic reconnection feature (reconnectOnClose) with configurable maxReconnectAttempts and reconnectInterval, enabling the client to gracefully recover from dropped connections.
  • Refactored Connection Logic: Centralized WebSocket connection establishment into a new _connect() method and updated the listen() method to integrate the new callbacks and reconnection logic, improving robustness and maintainability.

🧠 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

@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 onClose and onError callbacks, along with a reconnection mechanism, which are valuable additions. The implementation is generally solid, but I've identified a few areas for improvement regarding code duplication, error handling, and the reconnection strategy to enhance maintainability and robustness. My detailed feedback is in the comments below.

Comment on lines +38 to +46
Future<void> _connect() async {
try {
final wsUrl = _constructWebSocketUrl();
_channel = WebSocketChannel.connect(Uri.parse(wsUrl));
} catch (e) {
_logger.e('Failed to connect to WebSocket: $e');
rethrow;
}
}

Choose a reason for hiding this comment

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

medium

The logic inside this new _connect method is identical to the connection logic in the SimpleFlutterReverb constructor (lines 28-36). Duplicating code can lead to maintenance issues where a bug fix or change is applied in one place but not the other. To adhere to the Don't Repeat Yourself (DRY) principle, this logic should be consolidated into a single private method that is called by both the constructor and the reconnect logic.

Comment on lines +142 to +145
final wait = Duration(
milliseconds:
options.reconnectInterval.inMilliseconds * attempt,
);

Choose a reason for hiding this comment

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

medium

The current implementation uses a linear backoff for reconnection attempts (interval * attempt). While this is better than a fixed interval, an exponential backoff strategy is generally recommended for network reconnections. Exponential backoff helps to prevent a "thundering herd" problem where many clients try to reconnect simultaneously after a service disruption, and it spreads out connection attempts more effectively over time.

You can achieve exponential backoff using a bitwise left shift, which avoids needing to import dart:math.

Suggested change
final wait = Duration(
milliseconds:
options.reconnectInterval.inMilliseconds * attempt,
);
final wait = Duration(
milliseconds:
options.reconnectInterval.inMilliseconds * (1 << (attempt - 1)),
);

Comment on lines +172 to +174
try {
_subscribe(channelName, null);
} catch (_) {}

Choose a reason for hiding this comment

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

medium

Swallowing exceptions silently using an empty catch block is generally discouraged as it can hide important issues during development and in production. If an error occurs during the initial subscription attempt, it should at least be logged for debugging purposes.

Suggested change
try {
_subscribe(channelName, null);
} catch (_) {}
try {
_subscribe(channelName, null);
} catch (e) {
_logger.w('Initial subscribe attempt failed, will retry on connection: $e');
}

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