Skip to content

feat: implement network error handling and recovery for stmt2 operations#112

Closed
qevolg wants to merge 1 commit intofeat/main/failover4.0from
feat/main/failover4.0-stmt2-claude
Closed

feat: implement network error handling and recovery for stmt2 operations#112
qevolg wants to merge 1 commit intofeat/main/failover4.0from
feat/main/failover4.0-stmt2-claude

Conversation

@qevolg
Copy link
Copy Markdown
Contributor

@qevolg qevolg commented Mar 23, 2026

Description

Issue(s)

  • Close/close/Fix/fix/Resolve/resolve: Issue Link

Checklist

Please check the items in the checklist if applicable.

  • Is the user manual updated?
  • Are the test cases passed and automated?
  • Is there no significant decrease in test coverage?

@gemini-code-assist
Copy link
Copy Markdown

Summary of Changes

Hello, 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 resilience of stmt2 operations by introducing comprehensive network error handling and recovery. It refactors the statement execution flow to gracefully manage disconnections, allowing prepared statements to rebuild their context and retry operations without user intervention. This ensures greater stability and reliability for applications interacting with the database over potentially unstable network connections.

Highlights

  • Network Error Handling for Stmt2 Operations: Implemented robust network error handling and recovery mechanisms for stmt2 operations, ensuring that prepared statements can recover from transient network disconnections and continue execution.
  • Refactored Stmt2 Workflow: The WsStmt2 class was refactored to separate core statement execution logic (doInit, doPrepare, doSendBindBytes, doExec, doResult) from the error handling and retry logic, improving modularity and maintainability.
  • Context Rebuilding on Disconnect: A new rebuildContext method was introduced in WsStmt2 to re-establish the statement's state (init, prepare, bind) after a network error, allowing operations to resume from the point of failure.
  • Enhanced WsClient and WsConnector: The WsClient now exposes methods to check for network errors and wait for the connection to be ready, while WsConnector's isNetworkError method was made public to support broader error detection.
  • Comprehensive Failover Testing: New test cases were added to validate the stmt2 failover capabilities across various phases (bind, prepare, result) and under conditions of multiple network disconnects, ensuring the reliability of the recovery mechanism.

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

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
Copy Markdown

@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 network error handling and recovery for stmt2 operations, a valuable addition for client resilience. The implementation correctly saves statement context and replays operations upon network failure, centered around a rebuildContext method. The inclusion of a comprehensive test suite using a proxy to simulate failures is commendable. I have a couple of suggestions in wsStmt2.ts to enhance code clarity and robustness.

Comment on lines +414 to +417
await this.doPrepare(this._savedSql!);
if (failedStep === StmtStep.PREPARE) return;

await this.doSendBindBytes(this._savedBindBytes!);
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

medium

Using non-null assertion operators (!) on _savedSql and _savedBindBytes can be brittle. While the current logic ensures these are non-null, future changes might break this assumption and lead to runtime errors. For improved robustness and clearer error handling, it would be better to add explicit checks for undefined and throw a descriptive error if the properties are not set when expected.

Suggested change
await this.doPrepare(this._savedSql!);
if (failedStep === StmtStep.PREPARE) return;
await this.doSendBindBytes(this._savedBindBytes!);
if (this._savedSql === undefined) {
throw new TaosResultError(ErrorCode.ERR_INVALID_PARAMS, "Internal error: _savedSql is undefined during rebuild.");
}
await this.doPrepare(this._savedSql);
if (failedStep === StmtStep.PREPARE) return;
if (this._savedBindBytes === undefined) {
throw new TaosResultError(ErrorCode.ERR_INVALID_PARAMS, "Internal error: _savedBindBytes is undefined during rebuild.");
}
await this.doSendBindBytes(this._savedBindBytes);

Comment on lines +418 to +419
if (failedStep === StmtStep.BIND) return;

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

medium

The StmtStep.BIND enum member and this check appear to be unused. The rebuildContext method is never called with StmtStep.BIND. In exec(), failures in both doSendBindBytes and doExec trigger a rebuild with StmtStep.EXEC. To improve clarity and remove dead code, consider removing the BIND step from the StmtStep enum and this conditional block.

@qevolg qevolg closed this Mar 26, 2026
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