Access response text of failed http actions in integration logs for ZIS
Feature Request Summary:
When an http action is unsuccessful (e.g. returns 400), I would like to see the response text in the integration logs and not just the code.
Description/Use Cases:
A ZIS app has multiple http actions. They can sometimes fail due to bad input and the error is caught as follows:
"SampleState": {
"Type": "Action",
"ActionName": "zis:sample_integration:action:zendesk.SampleApiCall",
"Parameters": {
"token.$": "$.connections.zendesk.access_token",
},
"Catch": [{
"ErrorEquals": ["States.ALL"],
"ResultPath": "$.failure_response",
"Next": "Terminator"
}],
"ResultPath": "$.success_response",
"Next": "NextState"
}
"Terminator": {
"Type": "Fail",
"Error": "Unexpected Response",
"Cause": "$.failure_response"
}
Unfortunately, the cause shown in the log is as follows:
map[Cause:external action failed due to status code: 400 Error:customError]
For troubleshooting, developer has to copy the input from the logs, replicate the indicated action in terminal/postman while carefully filling all the payload placeholders with input data. God forbid if some of it depends on responses to previous states. Eventually a helpful error description explains everything in the response text:
{
"errors": [
{
"id": "0x123",
"code": "ExternalIDExists",
"title": "A different external ID is present on the user"
}
]
}
It would be great to have access to this response text and store it in the ResultPath instead of it being overridden by $.Error and $.Cause objects.
Business impact of limitation or missing feature:
This is crucial to improve and speedup development of ZIS integrations.
-
Hi Ahmed, thanks for taking the time to provide some feedback on ZIS. I can see that you've mentioned that when a HTTP action is unsuccessful (e.g. returns 400), you would like to see the response body in the integration logs.
I can confirm that currently you are able to see the response body in the Integration Logs for a failed HTTP request when they are not wrapped by a Catch block.
So that I can capture your feedback correctly so that we can prioritize it accordingly, is your intention to be able to have the response body stored in the ResultPath so that you can see the response body in the Integration Logs even when you use a Catch block to handle the error?
-
Hello Zach Anthony,
Thank you so much for responding. I can indeed see the response body in the logs now if a catch block is not utilised. I am not sure if this has been added in the past year after I posted this feedback, or if I never tested an action without a catch block.
Anyway, you understood my feedback correctly. My intention is to catch the unsuccessful response, store the response body in the result path, and continue the flow. Here is an example use case:
Imagine a ZIS flow that enriches Zendesk user data by querying an external API to add a name and extra identities(email/phone/twitter) to Talk or messaging users. After acquiring the data, the flow makes a POST call using custom action to the Zendesk users API and/or identities API. It is possible that the one of the identities will be already associated with the same or a different user. In both cases, the catch block will indicate an error 400, but the response body will be overwritten. I would like to parse this response body, which would tell me exactly what the problem is, and continue my flow. For example, merging duplicate users or exit successfully when no action is needed.
I understand there are workarounds to this exact use case by making some extra API calls, but I just used it as an example.
-
Hey Ahmed, I think it's possible that this has been added in the past year after you posted this feedback, so hopefully this helps somewhat. Thanks for sharing an example use case though around being able to access the response body in the ResultPath. While I can't commit to actioning this feature request, I've noted your feature request internally and added this to our backlog. I'll be sure to reach out in future if I have any updates.
Por favor, entrar para comentar.
3 Comentários