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: do not request more work after an eval failure #37161

Merged
merged 1 commit into from
Nov 22, 2023

Conversation

efd6
Copy link
Contributor

@efd6 efd6 commented Nov 21, 2023

Proposed commit message

The logic for want_more is that there must be at least one event
published for a true want_more field to result in an additional loop of
evaluation. This condition can currently be true in the case that the
evaluation fails. In the failure case it is likely that we do not want
to re-eval, so set want_more to false in this situation.

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.

Author's Checklist

How to test this PR locally

Related issues

Use cases

Screenshots

Logs

@efd6 efd6 added enhancement Filebeat Filebeat Team:Security-External Integrations backport-skip Skip notification from the automated backport with mergify 8.12-candidate labels Nov 21, 2023
@efd6 efd6 self-assigned this Nov 21, 2023
@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 Nov 21, 2023
@efd6 efd6 force-pushed the cel_no_more_after_eval_fail branch 2 times, most recently from 786006c to f85c20b Compare November 21, 2023 00:47
@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Duration: 135 min 6 sec

❕ Flaky test report

No test was executed to be analysed.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

  • /package : Generate the packages and run the E2E tests.

  • /beats-tester : Run the installation tests with beats-tester.

  • run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

@efd6 efd6 marked this pull request as ready for review November 21, 2023 03:04
@efd6 efd6 requested a review from a team as a code owner November 21, 2023 03:04
@elasticmachine
Copy link
Collaborator

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

Copy link
Contributor

@bhapas bhapas left a comment

Choose a reason for hiding this comment

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

This PR looks good.

Just a thought.

Can the state be a struct with specific fields rather than holding them in a map with strings.
This way there is a clear representation of state and what it can hold?
This might also look cleaner to make state changes.

@efd6
Copy link
Contributor Author

efd6 commented Nov 21, 2023

No, that is not possible given the computation model that we are using.

Copy link
Contributor

mergify bot commented Nov 22, 2023

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b cel_no_more_after_eval_fail upstream/cel_no_more_after_eval_fail
git merge upstream/main
git push upstream cel_no_more_after_eval_fail

…lure

The logic for want_more is that there must be at least one event
published for a true want_more field to result in an additional loop of
evaluation. This condition can currently be true in the case that the
evaluation fails. In the failure case it is likely that we do not want
to re-eval, so set want_more to false in this situation.
@efd6 efd6 force-pushed the cel_no_more_after_eval_fail branch from f85c20b to 0b0bbce Compare November 22, 2023 09:36
@elasticmachine
Copy link
Collaborator

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Duration: 135 min 42 sec

❕ Flaky test report

No test was executed to be analysed.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

  • /package : Generate the packages and run the E2E tests.

  • /beats-tester : Run the installation tests with beats-tester.

  • run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

@efd6 efd6 merged commit 199075c into elastic:main Nov 22, 2023
20 checks passed
Scholar-Li pushed a commit to Scholar-Li/beats that referenced this pull request Feb 5, 2024
…lure (elastic#37161)

The logic for want_more is that there must be at least one event
published for a true want_more field to result in an additional loop of
evaluation. This condition can currently be true in the case that the
evaluation fails. In the failure case it is likely that we do not want
to re-eval, so set want_more to false in this situation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
8.12-candidate backport-skip Skip notification from the automated backport with mergify enhancement Filebeat Filebeat
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants