[
https://issues.apache.org/jira/browse/NIFI-15424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18051794#comment-18051794
]
Yuanhao Zhu commented on NIFI-15424:
------------------------------------
[~exceptionfactory] Hey David, just aligned again with our team and the
intention was that for some of the exceptions like socket timeout/unexpected
end of stream and http 429, they mostly are retriable, and they should be
retried internally already, which would simplify the error handling. Does that
make sense to you?
> InvokeHTTPProcessor: Add dedicated relationship for Java exceptions
> (transport/runtime) instead of routing to failure
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: NIFI-15424
> URL: https://issues.apache.org/jira/browse/NIFI-15424
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Reporter: Yuanhao Zhu
> Priority: Major
> Original Estimate: 20m
> Remaining Estimate: 20m
>
> *Problem*
> Today, if {{InvokeHTTP}} throws a Java exception during the HTTP call (e.g.
> network interruption, DNS failure, connect reset/timeout), it routes the
> FlowFile to the existing error/failure relationship and sets:
> * {{invokehttp.java.exception.class}}
> * {{invokehttp.java.exception.message}}
> This mixes “HTTP response failures” with “request didn’t complete due to
> Java/transport exception”, making downstream handling (retry/alerting) messy.
> *Proposal*
> Add a dedicated relationship, e.g. {{{}java_exception{}}}, and route
> FlowFiles there when the HTTP call fails due to a Java exception (no valid
> HTTP response obtained). Keep existing relationships unchanged for normal
> HTTP outcomes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
