Hi Russell, what about checking the flow.xml prior to deploying it into production use. Search for you particular processors and the <autoTerminatedRelationship>success</autoTerminatedRelationship> pattern. One can integrate such QA checks into CI/CD pipeline as we do using Jenkins.
Hope that helps. Michal On Fri, Mar 24, 2017 at 10:50 PM, Russell Bateman <r...@windofkeltia.com> wrote: > Thanks, Joe. > > (Sorry.) > > Yes, it seems overly big-brotherish. I mean, it's a tool, after all. It's > our down-streamer manager that asked if we could prohibit this possibility > for certain processors whose auto-termination has proved especially > dangerous. I'm exercising due diligence by asking. I may or may not > experiment with Aldrin's suggestion. I could emit a warning at least. > > Thanks to both of you. > > > On 03/24/2017 03:05 PM, Joe Witt wrote: >> >> Russell >> >> There is no way to block that while still allowing someone to have the >> ability to alter the flow. That said, you could certainly have a >> reporting task or script that runs over the provenance events to find >> any such cases. There would be a drop event and its details would >> tell you it was auto terminated. So you can't block them from doing >> it at present but you can make a naughty list and go talk to them >> afterward. >> >> I'm not sure I'd be a big fan of restricting it personally. >> >> Thanks >> Joe >> >> On Fri, Mar 24, 2017 at 4:55 PM, Russell Bateman <r...@windofkeltia.com> >> wrote: >>> >>> ...of a relationship? >>> >>> In some of our custom processors, we'd like to remove the possibility >>> from >>> our user of ever auto-terminating, in particular, selected processors' >>> failure relationships. (I realize that the user can "drain" the failures >>> away into paths that amount to auto-termination, but that should be >>> explicit.) >>> >>> Or does the community consider this to be purely a question of >>> self-discipline? >>> >>> Thanks. > >
