x-pack/filebeat/input/cel: fix handling of non-200/non-429 status codes #34002
Conversation
efd6
added
bug
Filebeat
botelastic
bot
added
needs_team
Previously, non-200/non-429 status codes would cause an immediate retry, resulting in spamming the server. Treat these responses as an error and wait until the next event period.
| return false, waitUntil, nil | ||
| default: |
There was a problem hiding this comment.
We should consider stratifying these.
|
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
💚 Flaky test reportTests succeeded. 🤖 GitHub commentsExpand to view the GitHub comments
To re-run your PR in the CI, just comment with:
|
x-pack/filebeat/input/cel/input.go
Outdated
| if status == "" { | ||
| status = "unknown status code" | ||
| } | ||
| state["events"] = map[string]interface{}{"error.message": fmt.Sprintf("failed http request with %s: %d", status, statusCode)} |
There was a problem hiding this comment.
The error.message will result in a key containing a dot. Can you please change that to produce {"error":{"message":....
There was a problem hiding this comment.
That should happen in the other error.message constructions too then.
Also make error.message structured to avoid dotted field names.
| func errorMessage(msg string) map[string]interface{} { | ||
| return map[string]interface{}{"error": map[string]interface{}{"message": msg}} | ||
| } |
There was a problem hiding this comment.
Query whether this should be
func errorMessage(msg ...string) map[string]interface{} {
return map[string]interface{}{"error": map[string]interface{}{"message": msg}}
}
|
Kudos, SonarCloud Quality Gate passed!
|
…es (#34002) (#34006) Previously, non-200/non-429 status codes would cause an immediate retry, resulting in spamming the server. Treat these responses as an error and wait until the next event period. Also make error.message structured to avoid dotted field names. (cherry picked from commit 64691d3) Co-authored-by: Dan Kortschak <[email protected]>
…es (#34002) Previously, non-200/non-429 status codes would cause an immediate retry, resulting in spamming the server. Treat these responses as an error and wait until the next event period. Also make error.message structured to avoid dotted field names.
What does this PR do?
Previously, non-200/non-429 status codes would cause an immediate retry, resulting in spamming the server. Treat these responses as an error and wait until the next event period.
Why is it important?
Checklist
CHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.Author's Checklist
How to test this PR locally
Related issues
Use cases
Screenshots
Logs