[
https://issues.apache.org/jira/browse/NIFI-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17413478#comment-17413478
]
endzeit commented on NIFI-7371:
-------------------------------
Hello [~pgrey],
thanks for reaching out to me about this! I would highly appreciate your
contribution to this. 👍🏻 Besides making use of the S3 processors provided by
NiFi, I've not used the AWS API directly, thus I cannot provide much useful
guidance.
>From a NiFi user point-of-view I would prefer having multiple outgoing
>relationships to handle different errors. An additional attribute might
>provide more details about the specific error. This way, handling different
>kinds of errors differently, should become quite easy.
I would assume which "categories" of errors to use for the relationships
depends mostly on the information exposed by the AWS API.
I'll gladly review your progress, if that's welcomed.
Thanks for picking this up.
> Improve error handling of S3 processors
> ---------------------------------------
>
> Key: NIFI-7371
> URL: https://issues.apache.org/jira/browse/NIFI-7371
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: 1.11.4
> Reporter: endzeit
> Assignee: Paul Grey
> Priority: Major
>
> Currently the S3 processors, such as FetchS3Object, only expose the
> relationsships "success" and "failure". However the are a multitute of
> reasons why an interaction with an S3 storage might fail.
> As of now there is no easy way of knowing why a flow file was directed to the
> "failure" relationsship just by the flow file itself.
> A way of finding out the reason might be to search for a corresponing log /
> bulletin entry.
> This seems rather complicated.
> A use case where having this information is useful could be when deciding
> whether
> * the action should be retried, e.g. on a timeout,
> * or the failure be handled, e.g. when the object for the specified key does
> not exists.
> I haven't looked much into the underlying AWS library yet as I wanted to
> discuss whether such an improvement is desired at all first?
> If so, should the information be exposed via
> * additional / other relationsships, such as in the FetchSFTP processor,
> * or rather an attribute added to the flow file, such as in the ValidateXml
> processor?
> This might also apply to other AWS processors but we just have come across
> the S3 processors as we use them quite regulary.
> Any thoughts or comments would be highly appreciated!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
