Copilot commented on code in PR #6847:
URL: https://github.com/apache/hive/pull/6847#discussion_r4181442433
##########
jdbc/src/java/org/apache/hive/jdbc/HiveStatement.java:
##########
@@ -246,37 +252,10 @@ private boolean
checkInvalidOperationHandle(TCloseOperationResp closeResp) {
if (status == null) {
return false;
}
- if (status.isSetErrorMessage()) {
- String errorMsg = status.getErrorMessage();
- if (errorMsg.contains("Invalid OperationHandle") ||
errorMsg.contains("Operation does not exist")) {
- LOG.warn("Ignoring benign close operation error: {}", errorMsg);
- return true;
- }
- }
- List<String> messages = status.getInfoMessages();
- if (messages != null && !messages.isEmpty()) {
- /*
- * Here we need to handle 2 different cases, which can happen in
CLIService.closeOperation, which actually does:
- *
sessionManager.getOperationManager().getOperation(opHandle).getParentSession().closeOperation(opHandle);
- */
- String message = messages.getFirst();
- if (message.contains("Invalid OperationHandle")) {
- /*
- * This happens when the first request properly removes the operation
handle, then second request arrives, calls
- * sessionManager.getOperationManager().getOperation(opHandle), and it
doesn't find the handle.
- */
- LOG.warn("'Invalid OperationHandle' on server side (messages: " +
messages + ")");
- return true;
- } else if (message.contains("Operation does not exist")) {
- /*
- * This is an extremely rare case, which represents a race condition
when the first and second request
- * arrives almost at the same time, both can get the OperationHandle
instance
- * from sessionManager's OperationManager, but the second fails,
because it cannot get it again from the
- * session's OperationManager, because it has been already removed in
the meantime.
- */
- LOG.warn("'Operation does not exist' on server side (messages: " +
messages + ")");
- return true;
- }
+ if (status.getErrorCode() ==
ErrorMsg.INVALID_OPERATION_HANDLE.getErrorCode() ||
+ status.getErrorCode() == ErrorMsg.OPERATION_NOT_EXIST.getErrorCode()) {
+ LOG.warn("Ignoring benign close operation error: {}",
status.getErrorMessage());
+ return true;
}
Review Comment:
This drops compatibility with HS2 versions that predate these vendor codes.
Such servers return these benign duplicate-close failures with error code
0/unset and put the text in `errorMessage` or `infoMessages`; the JDBC client
will now pass the response to `verifySuccessWithInfo` and fail the close. Keep
the code checks as the primary path, but retain the legacy message fallback
(and cover a code-0 response in the test).
This issue also appears in the following locations of the same file:
- line 409
- line 573
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
