[
https://issues.apache.org/jira/browse/NIFI-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831362#comment-17831362
]
Stephanie Ambrose edited comment on NIFI-12918 at 3/27/24 2:05 PM:
---
Okay, so after some back and forth here is my final conclusion to this bug:
I've submitted two PRs
[https://github.com/apache/nifi/pull/8572/checks] <-- for support/1.x branch
[https://github.com/apache/nifi/pull/8536/checks] <-- for main branch
Here is what's happening. If you run a versioned stateless flow that has
sub-versioned progress group, there is a NullPointerException thrown on the
build method of StandardVersionControlInformation where there is a non-null
requirement on "registryId".
Code has changed in main versus support/1.x, but the bug exists on both. What
I've found is the JerseyClient calls that are made to map the response from the
registry-api back to the higher level VersionedProcessGroup ->
VersionedFlowCoordinates both return JSON where the VersionedFlowCoordinates >
registryId is always null. Now in the main branch, stateless uses some of these
new "synchronizer" classes, so the best place to insert a solution is to add an
else on the null check where the code runs the "determineRegistryId" method and
set the value to "1" for versioned flows that do not have a registryId
associated to them. Doing this passes all of the integration tests and code
checks and fixes the bug. Since this class does not exist in the 1.x support
branch, my best solution is to just comment out the null check (this breaks
integration tests in main, but not in 1.x).
I continued to look further at this idea of a "registryId" within the registry
api code. The GET method on buckets/flow/version returns the same class that
the stateless code uses to map into on the JerseyClient call. I then looked at
the api code to POST new versioned flows, and it also expect the json as a
parameter to match the same class. Well, since there is no "non-null"
requirement on the registryId, versioned flows are stored in the database (or
whichever storage adapter used) with this property as null. I did not check to
see if the latest NiFi Registry UI is now setting this property, but making it
non-null would break any older version of registry and not be backwards
compatible. Therefore, the only solution at this point to fix stateless NiFi in
its current state is to just set registryId to "1" if it is null. I believe
this code is still probably prototype being worked and evolving, so this will
be a temporary fix until those mandates are in place on a concept of
"registryId".
[~markap14]
was (Author: JIRAUSER299049):
Okay, so after some back and forth here is my final conclusion to this bug:
I've submitted two PRs
[https://github.com/apache/nifi/pull/8572/checks] <-- for support/1.x branch
[https://github.com/apache/nifi/pull/8536/checks] <-- for main branch
Here is what's happening. If you run a versioned stateless flow that has
sub-versioned progress group, there is a NullPointerException thrown on the
build method of StandardVersionControlInformation where there is a non-null
requirement on "registryId".
Code has changed in main versus support/1.x, but the bug exists on both. What
I've found is the JerseyClient calls that are made to map the response from the
registry-api back to the higher level VersionedProcessGroup ->
VersionedFlowCoordinates both return JSON where the VersionedFlowCoordinates >
registryId is always null. Now in the main branch, stateless uses some of these
new "synchronizer" classes, so the best place to insert a solution is to add an
else on the null check where the code runs the "determineRegistryId" method and
set the value to "1" for versioned flows that do not have a registryId
associated to them. Doing this passes all of the integration tests and code
checks and fixes the bug. Since this class does not exist in the 1.x support
branch, my best solution is to just comment out the null check (this breaks
integration tests in main, but not in 1.x).
I continued to look further at this idea of a "registryId" within the registry
api code. The GET method on buckets/flow/version returns the same class that
the stateless code uses to map into on the JerseyClient call. I then looked at
the api code to POST new versioned flows, and it also expect the json as a
parameter to match the same class. Well, since there is no "non-null"
requirement on the registryId, versioned flows are stored in the database (or
whichever storage adapter used) with this property as null. I did not check to
see if the latest NiFi Registry UI is now setting this property, but making it
non-null would break any older version of registry and not be backwards
compatible. Therefore, the only solution at this point to fix stateless NiFi in
its current state is to just set registryId to
