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

Build 149 for 8.8 with status FAILURE - FAIL: x-pack/libbeat/management TestInputReload (20.01s) #36192

Closed
elasticmachine opened this issue Aug 1, 2023 · 4 comments · Fixed by #36185
Labels
automation build-failures Build failures in the CI. ci-reported Issues that have been automatically reported from the CI Team:Elastic-Agent-Data-Plane Label for the Agent Data Plane team

Comments

@elasticmachine
Copy link
Collaborator

💔 Build Failed

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

  • Start Time: 2023-08-01T08:19:19.570+0000

  • Duration: 127 min 53 sec

Test stats 🧪

Test Results
Failed 0
Passed 50365
Skipped 4667
Total 55032

Steps errors 2

Expand to view the steps failures

x-pack/libbeat-arm-ubuntu-2204-aarch64 - mage build unitTest
  • Took 4 min 22 sec . View more details here
  • Description: mage build unitTest
Google Storage Download
  • Took 0 min 5 sec . View more details here
  • Description: [2023-08-01T09:59:05.366Z] [Google Cloud Storage Plugin] Found 1 files to download from pattern: gs:

@elasticmachine elasticmachine added automation ci-reported Issues that have been automatically reported from the CI build-failures Build failures in the CI. Team:Elastic-Agent-Data-Plane Label for the Agent Data Plane team labels Aug 1, 2023
@elasticmachine
Copy link
Collaborator Author

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

@pierrehilbert pierrehilbert changed the title Build 149 for 8.8 with status FAILURE Build 149 for 8.8 with status FAILURE - FAIL: x-pack/libbeat/management TestInputReload (20.01s) Aug 1, 2023
@pierrehilbert
Copy link
Collaborator

@belimawr did we do something to fix this one on 8.9 branch and main?
Because it's not the first time I'm seeing this failure on 8.8.

@belimawr
Copy link
Contributor

belimawr commented Aug 2, 2023

There is a race condition on this tests, I have a PR open to fix this: #36185

I started a small thread about whether we should remove this test or not, there is an integration test that covers the same feature, so I believe it is safe to remove it.

I'll update the PR today removing this flaky test.

@belimawr
Copy link
Contributor

belimawr commented Aug 2, 2023

#36185 is ready for review!

belimawr added a commit that referenced this issue Aug 22, 2023
This commit fixes a number of race conditions in the ManagerV2
tests. Most of them were due to the use of Testify's Eventually
function to read some values while some callbacks from the manager
would also modify those values. The simplest solution was to use the
atomic values on those cases.

One test (TestInputReload) had a race condition between the test and
the manager itself, so it was removed. There is an integration tests
that covers the same functionality.

Closes #36192
mergify bot pushed a commit that referenced this issue Aug 29, 2023
This commit fixes a number of race conditions in the ManagerV2
tests. Most of them were due to the use of Testify's Eventually
function to read some values while some callbacks from the manager
would also modify those values. The simplest solution was to use the
atomic values on those cases.

One test (TestInputReload) had a race condition between the test and
the manager itself, so it was removed. There is an integration tests
that covers the same functionality.

Closes #36192

(cherry picked from commit 818c72d)
belimawr added a commit that referenced this issue Aug 31, 2023
This commit fixes a number of race conditions in the ManagerV2
tests. Most of them were due to the use of Testify's Eventually
function to read some values while some callbacks from the manager
would also modify those values. The simplest solution was to use the
atomic values on those cases.

One test (TestInputReload) had a race condition between the test and
the manager itself, so it was removed. There is an integration tests
that covers the same functionality.

Closes #36192

(cherry picked from commit 818c72d)

Co-authored-by: Tiago Queiroz <tiago.queiroz@elastic.co>
Scholar-Li pushed a commit to Scholar-Li/beats that referenced this issue Feb 5, 2024
This commit fixes a number of race conditions in the ManagerV2
tests. Most of them were due to the use of Testify's Eventually
function to read some values while some callbacks from the manager
would also modify those values. The simplest solution was to use the
atomic values on those cases.

One test (TestInputReload) had a race condition between the test and
the manager itself, so it was removed. There is an integration tests
that covers the same functionality.

Closes elastic#36192
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automation build-failures Build failures in the CI. ci-reported Issues that have been automatically reported from the CI Team:Elastic-Agent-Data-Plane Label for the Agent Data Plane team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants