http status codes not passed back to caller

[mzizzi]

In some cases it's useful for the caller to know the underlying http status code returned by requests. As of now, status codes never make their way back to the caller. This makes it difficult to decide how to proceed after a failed request. Just about every error that the API could throw is wrapped in something like {'errors': [...]}. This is fine for some use cases but unless we know every possible message that might end up in that datastruct we'll have a hard time knowing exactly how to proceed.

There is the option to set datadog.api._mute = False which will cause exceptions to bubble up to the caller. But in this case, things like ApiError are too broad to take make decisions on. e.g. I may wish to never retry a failed request due to a 403 or 404 but I certainly want to retry a request with that has failed with a 429.

#378 is related in that it's asking for a little more detail on failed requests. Maybe we pass both status codes and relevant headers back to the caller?

[nmuesch]

Hey, we just merged in #412 which allows you to retrieve the full response object from the previous request. This way you can access the status_code as well as the response headers in whichever cases make sense. Going to close this issue as this will be out in the next release. Thanks for the report!

[mzizzi]

I'd like to re-open this. The method of fetching the entire http response in #412 isn't sufficient for multi-threaded programs.

[nmuesch]

Posting an update here for completeness: we continued this discussion on the original PR. This was reimplemented in a more threadsafe way #414 that allows you to retrieve the full raw response object.

[nmuesch]

Reopening based on the note from #414

[github-actions]

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had activity in the last 30 days. Note that the issue will not be automatically closed, but this notification will remind us to investigate why there's been inactivity. Thank you for participating in the Datadog open source community.

If you would like this issue to remain open:

1. Verify that you can still reproduce the issue in the latest version of this project.

2. Comment that the issue is still reproducible and include updated details requested in the issue template.

[github-actions]

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had activity in the last 30 days. Note that the issue will not be automatically closed, but this notification will remind us to investigate why there's been inactivity. Thank you for participating in the Datadog open source community.

If you would like this issue to remain open:

1. Verify that you can still reproduce the issue in the latest version of this project.

2. Comment that the issue is still reproducible and include updated details requested in the issue template.

[zippolyte]

As discussed in #414, this is likely not something that we'll be able to do without and significant rework of the library while keeping backward compatibility.
However we are currently working on a new and fresh python library for interacting with Datadog's API that wouldn't have that issue. I can't share an exact ETA at the moment.