I vote for #1. So much of security is built on integrity, and so I would prefer a complete failure in order to emphasize the issue and hopefully obtain a faster resolution. Along those lines, it would also be the duty of Metron to make sure these errors are very apparent and the consequences are obvious. I can't tell you how many times I've seen an incident be prolonged or incorrectly resolved due to inaccurate or incomplete information.
Jon On Mon, Oct 17, 2016 at 12:49 PM Otto Fowler <ottobackwa...@gmail.com> wrote: > 1 for me. > The Stellar transformations are part of creating a compete document ( > along with the parsing ) that will be passed to other topologies for > further processing. Failure on either side should be an error. This avoids > inconsistency downstream and other problems. If Metron were to allow this, > then it should be a configurable ‘policy’, which defaulted to case 1. > > On October 17, 2016 at 12:15:54, Casey Stella (ceste...@gmail.com) wrote: > > Hi Everyone, > > When we have a Field Transformation which is in error in the parser, the > current behavior is to send the message in question to the error queue. I > wanted to have a discussion around what the correct state of affairs for > this is. > > The way I see it, we have one of two options: > > 1. Send the message to the error queue as it's consistent with what > would happen if a parser failed > 2. Skip the failed transformation > > Normally I would be in favor of 1 (which is current behavior), but we DO > have some information that we could pass on since the parser did succeed > even though the field transformations did not. > > I wanted to open this up for discussion and see if I could get a good > direction from the community. > > Best, > > Casey > -- Jon