AlertApi.get_request_status raises HTTP 404 errors

[asqui]

Calling AlertApi.get_request_status() immediately after create_alert() sometimes results in an ApiException with status == 404 being raised by get_request_status().

I believe the reason for this is that the alerts/requests/{id} REST endpoint may return a HTTP 404 status if the request has not started processing yet. This behaviour is not detailed in the Get Request Status documentation and is also quite counter-intuitive for a user of the SDK (or any other direct or indirect user of the REST API).

This was previously raised with Opsgenie support as internal ticket ALX-612 and I understand that this has been "resolved" by adding to the 404 response a header that indicates the request has not been processed yet. (I'm not sure why this path was chosen, rather than returning a normal 200 response for an outstanding request). This header is also not documented anywhere that I can see, and is not much help because every consumer of this REST endpoint (including all your language-specific SDKs) needs to keep this edge-case in mind and handle it appropriately!

In the case of the Python SDK, the only solution I can see is putting a retry loop to retry on HTTP 404s around any call to AlertApi.get_request_status() or SuccessResponse.retrieve_result() (or SuccessResponse.retrieve_resulting_action()... or access to the SuccessResponse..id property...) which seems rather cumbersome and unintuitive...

[mhamzak008]

I don't think that you need to put a retry loop around calls to SuccessResponse.retrieve_result() or SuccessResponse.retrieve_resulting_action() or while accessing the SuccessResponse..id property because they internally have a retry mechanism which retries until either a success response is returned or the Configuration.short_polling_max_retries is reached

[asqui]

So:

• 404 errors will get retried even though they are not in the default set of retry_http_response error codes, and
• if there was ever a bug in the API causing it to hit an invalid URL, the resultant 404 error would get retried for the maximum retry duration before failing.

Is my understanding correct?

[mhamzak008]

Yes, that's correct. We changed it to this implementation in #16 from the one where it was retrying for only some specific scenarios. And now, I am questioning the decision back then