I am using the Utilities: Call Rest API function in a resilient worklow. The workflow crashes with the following error message:
File "/usr/local/lib/python3.6/site-packages/resilient_lib/components/requests_common.py", line 138, in execute_call_v2 raise IntegrationError(msg) resilient_lib.components.integration_errors.IntegrationError: '404 Client Error: Processed for url: https://url_modified_in_public_forum:8843/ressource1/ressource2'
This is because of the line 142 and 143 in request_common.py :
# Raise error is bad status code is returned
response.raise_for_status()
I believe an 404 error (HTTP 404 : ressource not found) should not raise an error in this function. This is not an integration error, this is just the client trying to fetch a ressource that does not exists. The client could handle this error code itself, rather than stopping the workflow. I believe this line should be removed.
Describe How to Reproduce
To reproduce this error, make a resilient workflow with the function Utilities: Call Rest API and try to get a resource that does not exists on the server. The workflow stops with an error, and there is nothing to be done to recover from this state without manual intervention on the workflow. If an error was not raised, the client could handle this error itself and the workflow would not stop in this case.
Description
I am using the
Utilities: Call Rest APIfunction in a resilient worklow. The workflow crashes with the following error message:This is because of the line 142 and 143 in request_common.py :
I believe an 404 error (HTTP 404 : ressource not found) should not raise an error in this function. This is not an integration error, this is just the client trying to fetch a ressource that does not exists. The client could handle this error code itself, rather than stopping the workflow. I believe this line should be removed.
Describe How to Reproduce
To reproduce this error, make a resilient workflow with the function
Utilities: Call Rest APIand try to get a resource that does not exists on the server. The workflow stops with an error, and there is nothing to be done to recover from this state without manual intervention on the workflow. If an error was not raised, the client could handle this error itself and the workflow would not stop in this case.