[Flaky Test] github.com/elastic/beats/v7/x-pack/metricbeat/module/ibmmq/qmgr TestFetch

[elastic-vault-github-plugin-prod]

Flaky Test

• Test Name: TestFetch
• Scope: github.com/elastic/beats/v7/x-pack/metricbeat/module/ibmmq/qmgr
• File: N/A
• Location: N/A
• Buildkite Link: https://buildkite.com/organizations/elastic/analytics/suites/beats/tests/34d06ebf-a42f-8fe8-9d75-281d0f362449
• Flaky Instances: 1
• Latest Occurrence: 2026-05-06T16:30:15.646Z

Details

{
  "id": "34d06ebf-a42f-8fe8-9d75-281d0f362449",
  "web_url": "https://buildkite.com/organizations/elastic/analytics/suites/beats/tests/34d06ebf-a42f-8fe8-9d75-281d0f362449",
  "scope": "github.com/elastic/beats/v7/x-pack/metricbeat/module/ibmmq/qmgr",
  "name": "TestFetch",
  "location": null,
  "file_name": null,
  "instances": 1,
  "latest_occurrence_at": "2026-05-06T16:30:15.646Z",
  "most_recent_instance_at": "2026-05-06T16:30:15.646Z",
  "last_resolved_at": null,
  "ownership_team_ids": [],
  "failure_examples": []
}

[github-actions]

tl;dr: the most likely cause of this flake is a startup-timeout mismatch — TestFetch waits only 60s for ibmmq health, while the container healthcheck allows up to 90 retries, so slower boots can intermittently time out.

Recommendation
Update TestFetch to use an explicit longer compose timeout (for example 2-5 minutes) when bringing up ibmmq, matching known slow-start integration patterns in this repo.

Findings

1. x-pack/metricbeat/module/ibmmq/qmgr/qmgr_integration_test.go:32 starts the service with default timeout:

service := compose.EnsureUp(t, "ibmmq")

2. libbeat/tests/compose/compose.go:49-51 documents and libbeat/tests/compose/compose.go:70-71 sets the default to 60s:

// EnsureUp ... with a default timeout of 60 seconds.
Timeout: 60 * time.Second,

3. libbeat/tests/compose/project.go:157-188 waits until healthy and returns timeout error if still unhealthy:

// Wait ensures all wanted services are healthy. Wait loop (60s timeout)
...
return errors.New("timeout waiting for services to be healthy")

4. x-pack/metricbeat/module/ibmmq/_meta/Dockerfile:11 configures a healthcheck with --retries=90:

HEALTHCHECK --interval=1s --retries=90 CMD curl -s --fail (127.0.0.1/redacted) | grep -q "ibmmq_qmgr_commit_total"

5. Comparable slow-start tests in this repo already extend timeout explicitly, e.g. x-pack/metricbeat/module/redisenterprise/node/node_integration_test.go:31:

service := compose.EnsureUp(t, "redisenterprise", compose.UpWithTimeout(5*time.Minute))

Verification

I ran the scoped integration test command:

go test -v -tags integration -run TestFetch -count=1 ./x-pack/metricbeat/module/ibmmq/qmgr

Output in this environment:

=== RUN   TestFetch
... qmgr_integration_test.go:32: listing containers to be killed: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
--- FAIL: TestFetch (0.00s)
FAIL

So I could not reproduce the flake end-to-end locally here, but the code-level timeout mismatch is concrete.

Detailed Action Plan

1. In x-pack/metricbeat/module/ibmmq/qmgr/qmgr_integration_test.go, change TestFetch service startup to pass a longer timeout:
   • from compose.EnsureUp(t, "ibmmq")
   • to compose.EnsureUp(t, "ibmmq", compose.UpWithTimeout(<duration>))
2. Add/import time in that file and set <duration> to a conservative value (start with 2*time.Minute; increase to 5*time.Minute if CI still shows startup timeout flakes).
3. Re-run only this test repeatedly in CI-capable env:
   • go test -v -tags integration -run TestFetch -count=20 ./x-pack/metricbeat/module/ibmmq/qmgr
4. If flakes persist, capture container health transition timing from compose logs and tune timeout based on observed startup distribution.

Related Items

Type	Link/Path	Relevance
Issue	#50540	Current flaky-test report
File	x-pack/metricbeat/module/ibmmq/qmgr/qmgr_integration_test.go:32	Uses default EnsureUp timeout
File	libbeat/tests/compose/compose.go:49-51	Default timeout documented as 60s
File	libbeat/tests/compose/compose.go:70-71	Default timeout implementation
File	libbeat/tests/compose/project.go:157-188	Wait loop timeout behavior
File	x-pack/metricbeat/module/ibmmq/_meta/Dockerfile:11	IBM MQ healthcheck retries set to 90
File	x-pack/metricbeat/module/redisenterprise/node/node_integration_test.go:31	Existing precedent using extended timeout

Note

🔒 Integrity filter blocked 12 items

The following items were blocked because they don't meet the GitHub integrity level.

• #50540 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #50540 issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #28153 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #28127 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #28147 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #28113 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #28084 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #28039 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #28038 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #28037 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #28051 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #28027 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

---

What is this? | From workflow: Issue Triage

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.