Github user jvwing commented on the issue:
    @vegaed Thanks for the updated code.  The situation with 
AbstractAWSProcessor is a bit odd.  It's deprecated in that you should not 
derive directly from it, but it still has live code we're definitely using.
    * **Number Parsing Exception Handling** - I tested with a non-double metric 
value.  A java.lang.NumberFormatException is thrown parsing the number at  The error message is clear enough, but the 
exception is not caught inside onTrigger(), so the entire session is rolled 
back and the flowfile remains in the incoming queue.  The same thing applies to 
parsing Timestamp.  Shouldn't we catch the exception and route the flowfile to 
failure in a case like this?
    * **Integration Tests** - Integration tests failed for me, complaining 
about no flowfiles routed to REL_SUCCESS.  I believe the fix might be as simple 
as adding an empty flowfile before running:
            runner.enqueue(new byte[] {});
    * **Unit Tests** - How about some unit tests that do not call AWS?  I agree 
there is no substitute for integration tests that actually call AWS, but I 
believe there is also no substitute for unit tests that can easily be run by 
anyone and everyone.  This can be a bit tricky for cloud services, but it seems 
like CloudWatch has an API with nice request/response patterns that can be 
mocked.  So I tried my hand at a [simple mock setup with sample tests for 
  You're welcome to not use this, but I recommend we try something similar that 
gets coverage of onTrigger from unit tests.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

Reply via email to