Github user jvwing commented on the issue:
https://github.com/apache/nifi/pull/1125
@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
PutCloudWatchMetric.java:174. 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[] {});
runner.run();
* **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
PutCloudWatchMetric](https://github.com/jvwing/nifi/commit/b6ae1accfecb464fe16a456cdef04669a65672fe).
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
