[
https://issues.apache.org/jira/browse/NIFI-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16606365#comment-16606365
]
ASF GitHub Bot commented on NIFI-5577:
--------------------------------------
Github user bbende commented on the issue:
https://github.com/apache/nifi/pull/2995
I believe the existing code in the finally block was there as a result of
an older approach where locking was being performed in the revision manager,
but since that is no longer needed, I believe it can be much simpler, similar
to how the deleteRevision works.
> Component revision number can be incorrectly changed during a failed update
> ---------------------------------------------------------------------------
>
> Key: NIFI-5577
> URL: https://issues.apache.org/jira/browse/NIFI-5577
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.7.1
> Reporter: Bryan Bende
> Assignee: Bryan Bende
> Priority: Minor
>
> When an update of a component throws an exception, the revision number is
> incorrectly set to whatever the client passed in, and since clients are
> allowed to keep making requests without the latest revision number this means
> the revision number can incorrectly set back to some lower number.
> Steps to reproduce...
> * Create a GenerateFlowFile processor and get back revision 1
> * Change the name three times and get to revision 4
> * Submit an update where the revision is 1 and set the state to RUNNING
> which should fail because the component is invalid
> * Perform a GET for the processors and notice the revision is now 1 and not 4
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
