[ https://issues.apache.org/jira/browse/NIFI-5834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16700095#comment-16700095 ]
ASF GitHub Bot commented on NIFI-5834: -------------------------------------- Github user ijokarumawak commented on a diff in the pull request: https://github.com/apache/nifi/pull/3179#discussion_r236571657 --- Diff: nifi-nar-bundles/nifi-hive-bundle/nifi-hive3-processors/src/main/java/org/apache/nifi/processors/hive/PutHive3QL.java --- @@ -148,7 +148,23 @@ public void constructProcess() { if (e instanceof SQLNonTransientException) { return ErrorTypes.InvalidInput; } else if (e instanceof SQLException) { - return ErrorTypes.TemporalFailure; + // Use the SQLException's vendor code for guidance -- see Hive's ErrorMsg class for details on error codes + int errorCode = ((SQLException) e).getErrorCode(); --- End diff -- I think that's a good idea :) > Restore default PutHiveQL error handling behavior > ------------------------------------------------- > > Key: NIFI-5834 > URL: https://issues.apache.org/jira/browse/NIFI-5834 > Project: Apache NiFi > Issue Type: Bug > Components: Extensions > Reporter: Matt Burgess > Assignee: Matt Burgess > Priority: Major > > As part of adding Rollback On Failure to PutHiveQL (via NIFI-3415), the code > was refactored to allow failures to be rolled back rather than transferred to > the failure relationship (if Rollback On Failure is set). As part of that, > all transient SQLExceptions were declared to be of type "Temporal Failure". > This (along with the refactor) allowed the failures to be handled as > rollbacks or transfers as specified. > Hive returns all exceptions as transient SQLExceptions, with an error code > that better infers the behavior of the operation. This, via the discovery of > NIFI-5045, resulted in the handling of error codes within the Hive error code > range. However the default behavior when the error code is not in the > Hive-valid range is to rollback regardless of whether Rollback On Failure is > true or not. This was done as a "better safe than sorry" approach, but it > made the behavior inconsistent with earlier versions of the processor, where > failures were simply routed to failure rather than rolling back. > This case proposes to return the default behavior for unknown SQLExceptions > to "TemporalFailure", which will make the behavior consistent with previous > versions of the processor, where unknown errors will be transferred to > failure unless Rollback on Failure is true. -- This message was sent by Atlassian JIRA (v7.6.3#76005)