Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x-pack/filebeat/input/{cel,salesforce}: check response for nilness before logging #40144

Merged
merged 1 commit into from
Jul 9, 2024

Conversation

efd6
Copy link
Contributor

@efd6 efd6 commented Jul 9, 2024

Proposed commit message

It turns out that retryablehttp will pass a nil *http.Response to the client's ErrorHandler function although this is not documented. In the cases where we are using this, this will result in a nil deference panic when the retries exceed their maximum. So, check for nilness to avoid this.

Checklist

  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have made corresponding change to the default configuration files
  • I have added tests that prove my fix is effective or that my feature works
  • I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Disruptive User Impact

Author's Checklist

  • [ ]

How to test this PR locally

Related issues

Use cases

Screenshots

Logs

@efd6 efd6 added Filebeat Filebeat bugfix Team:Security-Service Integrations Security Service Integrations Team backport-8.15 Automated backport to the 8.15 branch with mergify labels Jul 9, 2024
@efd6 efd6 self-assigned this Jul 9, 2024
@botelastic botelastic bot added needs_team Indicates that the issue/PR needs a Team:* label and removed needs_team Indicates that the issue/PR needs a Team:* label labels Jul 9, 2024
…fore logging

It turns out that retryablehttp will pass a nil *http.Response to the
client's ErrorHandler function although this is not documented. In the
cases where we are using this, this will result in a nil deference
panic when the retries exceed their maximum. So, check for nilness to
avoid this.
@efd6 efd6 marked this pull request as ready for review July 9, 2024 03:37
@efd6 efd6 requested review from a team as code owners July 9, 2024 03:37
@elasticmachine
Copy link
Collaborator

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

Copy link
Member

@andrewkroh andrewkroh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@efd6 efd6 merged commit b056515 into elastic:main Jul 9, 2024
16 of 19 checks passed
mergify bot pushed a commit that referenced this pull request Jul 9, 2024
…fore logging (#40144)

It turns out that retryablehttp will pass a nil *http.Response to the
client's ErrorHandler function although this is not documented. In the
cases where we are using this, this will result in a nil deference
panic when the retries exceed their maximum. So, check for nilness to
avoid this.

(cherry picked from commit b056515)
andrewkroh pushed a commit that referenced this pull request Jul 23, 2024
…fore logging (#40144) (#40159)

It turns out that retryablehttp will pass a nil *http.Response to the
client's ErrorHandler function although this is not documented. In the
cases where we are using this, this will result in a nil deference
panic when the retries exceed their maximum. So, check for nilness to
avoid this.

(cherry picked from commit b056515)

Co-authored-by: Dan Kortschak <dan.kortschak@elastic.co>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport-8.15 Automated backport to the 8.15 branch with mergify bugfix Filebeat Filebeat Team:Security-Service Integrations Security Service Integrations Team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants