Recent commit 00068f7 (PR #51864) moves the fb.runReady.Close() defer below b.Manager.PreInit(), leaving one early-exit path without the readiness signal.
Breaking Changes
Filebeat Manager.PreInit failures wait five seconds during shutdown
Commit: 00068f7
PR: #51864
What broke: In filebeat/beater/filebeat.go:314-316, Run returns immediately when b.Manager.PreInit() fails. The new defer fb.runReady.Close() is installed only at filebeat/beater/filebeat.go:327-333, so that return path never closes runReady.ch. If the manager cleanup invokes Filebeat.StopWithContext, filebeat/beater/filebeat.go:610-617 waits for the five-second timeout before proceeding.
The parent version installed defer fb.runReady.Close() before PreInit, so this behavior changed specifically in commit 00068f7963. x-pack/libbeat/management/managerV2.go:298-307 shows that PreInit can return an error, making this reachable for Elastic Agent-managed Filebeat.
Why undocumented: PR #51864 describes the change as affecting only internal shutdown sequencing and states “None” for disruptive user impact; it has the skip-changelog label and adds no release or documentation note. The PR description also claims the new ordering covers “every early-exit error path,” but PreInit is before the defer.
Suggested fix: Install the readiness-close defer before PreInit while preserving the manager cleanup ordering, or explicitly close runReady on the PreInit error path. Add a regression test covering PreInit failure and asserting shutdown does not wait for the five-second timeout.
Suggested Actions
What is this? | From workflow: Breaking Change Detect
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
Recent commit 00068f7 (PR #51864) moves the
fb.runReady.Close()defer belowb.Manager.PreInit(), leaving one early-exit path without the readiness signal.Breaking Changes
Filebeat
Manager.PreInitfailures wait five seconds during shutdownCommit: 00068f7
PR: #51864
What broke: In
filebeat/beater/filebeat.go:314-316,Runreturns immediately whenb.Manager.PreInit()fails. The newdefer fb.runReady.Close()is installed only atfilebeat/beater/filebeat.go:327-333, so that return path never closesrunReady.ch. If the manager cleanup invokesFilebeat.StopWithContext,filebeat/beater/filebeat.go:610-617waits for the five-second timeout before proceeding.The parent version installed
defer fb.runReady.Close()beforePreInit, so this behavior changed specifically in commit00068f7963.x-pack/libbeat/management/managerV2.go:298-307shows thatPreInitcan return an error, making this reachable for Elastic Agent-managed Filebeat.Why undocumented: PR #51864 describes the change as affecting only internal shutdown sequencing and states “None” for disruptive user impact; it has the
skip-changeloglabel and adds no release or documentation note. The PR description also claims the new ordering covers “every early-exit error path,” butPreInitis before the defer.Suggested fix: Install the readiness-close defer before
PreInitwhile preserving the manager cleanup ordering, or explicitly closerunReadyon thePreIniterror path. Add a regression test coveringPreInitfailure and asserting shutdown does not wait for the five-second timeout.Suggested Actions
Manager.PreInitfailures.PreIniterror path.What is this? | From workflow: Breaking Change Detect
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.