-
Notifications
You must be signed in to change notification settings - Fork 20
fix: Destination Service Error Handling #555
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Try<String> maybeBody = Try.of(() -> HttpEntityUtil.getResponseBody(response)); | ||
String logMessage = "Destination service returned HTTP status %s (%s)"; | ||
if( maybeBody.isFailure() ) { | ||
final var ex = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(used var
for better formatting)
...rc/test/java/com/sap/cloud/sdk/cloudplatform/connectivity/DestinationServiceAdapterTest.java
Outdated
Show resolved
Hide resolved
…AP/cloud-sdk-java into fix/destination-service-error-handling
requestUri)); | ||
} | ||
Try<String> maybeBody = Try.of(() -> HttpEntityUtil.getResponseBody(response)); | ||
String logMessage = "Destination service returned HTTP status %s (%s)"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Comment)
I'm not a fan of the dynamic string construction for log- and exception-messages. I know the format string %s
is different from the log string template {}
but I'm not sure the solution is the "best" practice yet.
The dynamic construction makes the code below complicated and during troubleshooting, we have to think twice, how a messages maps a corresponding piece of code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same, I felt this was a tradeoff between complex code vs. code duplication. Maybe at some point we switch to a more high-level HTTP client, where we don't have to re-implement this response handling every time 😄
Context
This fixes a bug that would cause HTTP connections to stay open in case the destination service returns an error with payload. Which is the case for e.g. 404 responses.
Definition of Done
Error handling created / updated & covered by the tests aboveDocumentation updated