slambrose commented on PR #8572:
URL: https://github.com/apache/nifi/pull/8572#issuecomment-2022844115

   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 "reg
 istryId". 


-- 
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: issues-unsubscr...@nifi.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to