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: avoid a negative request rate #40270

Merged
merged 1 commit into from
Jul 24, 2024

Conversation

efd6
Copy link
Contributor

@efd6 efd6 commented Jul 16, 2024

This is the minimal change necessary to fix the following problem.

Around the time of a rate limit reset, if current time is after the reset time returned in response headers, the rate limiting code will set a negative target rate, and if that's done at a time when no request budget has accumulated, it will not recover and will wait forever.

Proposed commit message

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-v8.14.0 Automated backport with mergify backport-8.15 Automated backport to the 8.15 branch with mergify labels Jul 16, 2024
@efd6 efd6 self-assigned this Jul 16, 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 16, 2024
This is the minimal change necessary to fix the following problem.

Around the time of a rate limit reset, if current time is after the
reset time returned in response headers, the rate limiting code will
set a negative target rate, and if that's done at a time when no
request budget has accumulated, it will not recover and will wait
forever.
@efd6 efd6 requested a review from chrisberkhout July 16, 2024 21:42
@efd6 efd6 marked this pull request as ready for review July 16, 2024 23:38
@efd6 efd6 requested a review from a team as a code owner July 16, 2024 23:38
@elasticmachine
Copy link
Collaborator

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

@efd6 efd6 merged commit de8c76d into elastic:main Jul 24, 2024
16 of 19 checks passed
mergify bot pushed a commit that referenced this pull request Jul 24, 2024
This is the minimal change necessary to fix the following problem.

Around the time of a rate limit reset, if current time is after the
reset time returned in response headers, the rate limiting code will
set a negative target rate, and if that's done at a time when no
request budget has accumulated, it will not recover and will wait
forever.

(cherry picked from commit de8c76d)
mergify bot pushed a commit that referenced this pull request Jul 24, 2024
This is the minimal change necessary to fix the following problem.

Around the time of a rate limit reset, if current time is after the
reset time returned in response headers, the rate limiting code will
set a negative target rate, and if that's done at a time when no
request budget has accumulated, it will not recover and will wait
forever.

(cherry picked from commit de8c76d)
efd6 added a commit that referenced this pull request Jul 25, 2024
…0344)

This is the minimal change necessary to fix the following problem.

Around the time of a rate limit reset, if current time is after the
reset time returned in response headers, the rate limiting code will
set a negative target rate, and if that's done at a time when no
request budget has accumulated, it will not recover and will wait
forever.

(cherry picked from commit de8c76d)

Co-authored-by: Dan Kortschak <dan.kortschak@elastic.co>
efd6 added a commit that referenced this pull request Jul 25, 2024
…equest rate (#40343)

* x-pack/filebeat/input/cel: avoid a negative request rate (#40270)

This is the minimal change necessary to fix the following problem.

Around the time of a rate limit reset, if current time is after the
reset time returned in response headers, the rate limiting code will
set a negative target rate, and if that's done at a time when no
request budget has accumulated, it will not recover and will wait
forever.

(cherry picked from commit de8c76d)

* remove irrelevant changelog entries

---------

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 backport-v8.14.0 Automated backport 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.

3 participants