[9.4](backport #51911) handle PreInit error case for runReady.Close

[mergify]

Proposed commit message

WHAT

filebeat/beater: close runReady on Manager.PreInit failure

PR #51864 (commit 00068f7) reordered the defers in Filebeat.Run so that defer fb.runReady.Close() runs before the managerEarlyStop defer (correct LIFO ordering to avoid a 5-second wait when the manager's stop callback calls StopWithContext). However, both defers were placed after the b.Manager.PreInit() call. If PreInit returns an error, Run exits before either defer is registered, leaving runReady.ch permanently unclosed.

An unclosed runReady.ch means any subsequent call to StopWithContext (e.g. via a SIGINT-triggered Manager.Stop that invokes the beat stop callback) will wait the full 5-second timeout before proceeding, rather than returning immediately.

WHY

Restores the invariant from before #51864: runReady is closed regardless of how Run exits. The fix adds an explicit fb.runReady.Close() on the PreInit error return path, which is the one path the deferred close cannot reach. A new unit test TestRunClosesRunReadyOnPreInitFailure directly asserts the channel is closed after Run returns due to a PreInit error; confirmed to fail against the buggy code and pass with the fix.

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. Where relevant, I have used the stresstest.sh script to run them under stress conditions and race detector to verify their stability.
• I have added an entry in ./changelog/fragments using the changelog tool.

Disruptive User Impact

None. This is an internal shutdown-sequencing fix. The only observable change is that Elastic Agent-managed Filebeat instances where PreInit fails will no longer incur a spurious 5-second delay during shutdown.

How to test this PR locally

go test ./filebeat/beater/ -run "TestRunClosesRunReadyOnPreInitFailure|TestStopWaitsForRunReady" -v -count=1 -race

Related issues

• Relates managerEarlyStop before runReady close #51864
• Related synchronize filebeat run and shutdown functions #51800
• Closes [breaking-change] Undocumented breaking change: Filebeat PreInit errors now incur a 5-second shutdown timeout #51893

Use cases

Screenshots

Logs

---

This is an automatic backport of pull request #51911 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of 397822f has failed:

On branch mergify/bp/9.4/pr-51911
Your branch is up to date with 'origin/9.4'.

You are currently cherry-picking commit 397822f0b.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   filebeat/beater/filebeat.go

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
	deleted by us:   filebeat/beater/stop_test.go

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[github-actions]

🤖 GitHub comments

Just comment with:

• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)
• /test : Run the Buildkite pipeline.

[infra-vault-gh-plugin-prod]

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

[github-actions]

TL;DR

The 9.4 backport is failing because the resolved PR head adds fb.runReady.Close() and tests that use runReady, but the backport branch does not contain the prerequisite runReady implementation from #51864. This is an incomplete cherry-pick/conflict resolution, not a failure in the new PreInit behavior.

Remediation

• Re-resolve the backport by first carrying over the complete managerEarlyStop before runReady close #51864 lifecycle change (or manually port its equivalent): the Filebeat.runReady field/initialization, closeOnce helper, StopWithContext wait, and defer ordering in Run; then reapply the one-line PreInit close from handle PreInit error case for runReady.Close #51911 and retain the regression tests.
• Re-run make -C filebeat check update && make check-no-changes, plus go test ./filebeat/beater/ -run "TestRunClosesRunReadyOnPreInitFailure|TestStopWaitsForRunReady" -v -count=1 -race.

Investigation details

Root Cause

The failed job reports beater/filebeat.go:297:6: fb.runReady undefined (type *Filebeat has no field or method runReady) during go vet. The PR diff adds fb.runReady.Close() in Run and adds stop_test.go, which also constructs Filebeat with runReady; neither can compile unless the earlier runReady lifecycle change is present. In the fixed implementation, the supporting pieces are in filebeat/beater/filebeat.go:86 (field), :178 (initialization), :614-618 (shutdown wait), and :636-644 (closeOnce).

The PR already has a Mergify conflict comment documenting that cherry-picking 397822f0 failed with filebeat/beater/stop_test.go deleted by the 9.4 branch, consistent with the incomplete resolution.

Evidence

• Build: https://buildkite.com/elastic/beats/builds/49392
• Job/step: Filebeat: Run check/update — https://buildkite.com/elastic/filebeat/builds/34475
• Key log excerpt: beater/filebeat.go:297:6: fb.runReady undefined (type *Filebeat has no field or method runReady); Error: failed running go vet
• PR: [9.4](backport #51911) handle PreInit error case for runReady.Close #51930 cherry-picks handle PreInit error case for runReady.Close #51911, whose parent fix depends on managerEarlyStop before runReady close #51864

Verification

• Targeted tests passed on the repository fixed implementation: go test ./filebeat/beater -run TestRunClosesRunReadyOnPreInitFailure|TestStopWaitsForRunReady -count=1
• The failing 9.4 Buildkite check cannot pass until the missing prerequisite lifecycle code is restored.

---

What is this? | From workflow: PR Buildkite Detective

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

[mergify]

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 mergify/bp/9.4/pr-51911 upstream/mergify/bp/9.4/pr-51911
git merge upstream/9.4
git push upstream mergify/bp/9.4/pr-51911