ti_crowdstrike: improve error reporting for unsuccessful API requests #9059
Conversation
Previously, failed requests would continue through the standard happy path, potentially resulting in an uninfortive CEL error when the data shape does not match the program's expectations. We have the HTTP status code, so make use of this to return an error object in the case that we get a non-success.
efd6
added
enhancement
| }, | ||
| })) | ||
| ).do_request().as(resp, | ||
| resp.StatusCode == 200 ? |
There was a problem hiding this comment.
Query whether we know for sure that Crowdstrike always returns a 200 status for success.
🚀 Benchmarks reportTo see the full report comment with |
💚 Build Succeeded
cc @efd6 |
|
|
Pinging @elastic/security-service-integrations (Team:Security-Service Integrations) |
|
This could be tested if system tests allowed us to tolerate errors and make assertions about index documents. |
|
Customer (and CrowdStrike user) here... per their API specification swagger page, it will always return a 200 for both API endpoints that I believe are being used by this integration. This corresponds to what I have seen in my testing as well. I hope this is helpful! |
|
@NateUT99 Thank you, this is very helpful. |
Proposed commit message
Previously, failed requests would continue through the standard happy path, potentially resulting in an uninformative CEL error when the data shape does not match the program's expectations. We have the HTTP status code, so make use of this to return an error object in the case that we get a non-success.
Checklist
changelog.ymlfile.Author's Checklist
How to test this PR locally
Related issues
Screenshots