Santiago, OK great, i’m glad you were able to get it working. So I think the issue is that the script, when the getRelationships() method is called, should return a Set<Relationship> but appears to return a Set<ArrayList> - probably a Set<ArrayList<Relationship>>. But the Objects that are in that Set are not of type Relationship - they are of type ArrayList.
So that’s causing Validation to fail. I think the validation is unrelated, but that same problem was causing failures elsewhere also. So when you disabled and restarted, the processor will have not parsed the script so it’s only returning the relationships it knows about, so it’s working. Hope this helps to clarify what’s happening! Thanks -Mark On Mar 11, 2021, at 1:55 PM, Santiago Acosta <[email protected]<mailto:[email protected]>> wrote: I was successfull in recreating my experimental setup and the issue. With what you told me about disabled processors, I understand know that a service restart would be unhindered by the misbehaving processor. The restart was successful and the restart on my original experimental setup was also successful. I could then access the PG and delete the InvokeScriptedProcessor. If anyone ever comes across this issue, keep in mind that it may have only worked because I was able to disable the entire PG (including the misbehaving one). I believe that the error only propagated to the point where my Parameter Context was defined as this processor was nested 2 or 3 levels deep. A diagram will help: NiFi Flow [still accessible] / PG (that defines a PContext1) [cannot access] / PG 1 (with PC1) / PG 2 (with PC1) / InvokeScriptedProcessor (misbehaving) I could still access any other PG from the root PG. I don't know if this is relevant but it was part of my setup. Thank you Mark. -- Best regards, Santiago
