[bug-hunter] add_agent_metadata processor rejects valid partial configs

Start in libbeat/processors/actions/add_agent_metadata.go:27-29 and compare its plugin registration with the optional-section handling in libbeat/processors/actions/addagentmetadata/add_agent_metadata.go:70-107. Review add_agent_metadata_test.go:116-165, then add or update coverage for processors.New with each partial configuration. Done means both configurations load successfully without breaking existing tests.

Impact

Users configuring the add_agent_metadata processor with only one optional section (data_stream or elastic_agent) get a hard startup/config error, even though the processor implementation and tests support either section independently. This blocks valid configurations and can prevent Beats startup.

Reproduction Steps

1. From repo root, create and run this minimal repro:

package main

import (
	"fmt"

	"github.com/elastic/beats/v7/libbeat/processors"
	_ "github.com/elastic/beats/v7/libbeat/processors/actions"
	conf "github.com/elastic/elastic-agent-libs/config"
	"github.com/elastic/elastic-agent-libs/logp/logptest"
)

func run(yml string) {
	cfg, err := conf.NewConfigWithYAML([]byte(yml), "repro")
	if err != nil {
		fmt.Printf("config parse error: %v\n", err)
		return
	}
	_, err = processors.New([]*conf.C{cfg}, logptest.NewTestingLogger(nil, ""))
	if err != nil {
		fmt.Printf("processors.New error: %v\n", err)
		return
	}
	fmt.Println("processors.New success")
}

func main() {
	fmt.Println("Case A: data_stream only")
	run(`add_agent_metadata:
  data_stream:
    dataset: system.cpu
    namespace: default
    type: metrics`)

	fmt.Println("Case B: elastic_agent only")
	run(`add_agent_metadata:
  elastic_agent:
    id: agent-123
    snapshot: false
    version: 9.3.0`)
}

2. Run:

go run /tmp/gh-aw/agent/repro_add_agent_metadata.go

3. Observed output:

Case A: data_stream only
processors.New error: missing elastic_agent option in add_agent_metadata
Case B: elastic_agent only
processors.New error: missing data_stream option in add_agent_metadata

Expected vs Actual

Expected: add_agent_metadata should accept configs with only data_stream or only elastic_agent when users only need one of these metadata blocks.

Actual: processor registration enforces both sections as required and fails config loading with missing ... option errors.

Failing Test

A minimal failing test can assert that processors.New succeeds for either of these configs:

• add_agent_metadata with only data_stream
• add_agent_metadata with only elastic_agent

Today both fail during config validation.

Evidence

• Plugin registration requires both fields:
  • libbeat/processors/actions/add_agent_metadata.go:27-29
• Implementation treats both sections as optional (nil checks and conditional updates):
  • libbeat/processors/actions/addagentmetadata/add_agent_metadata.go:70-89
  • libbeat/processors/actions/addagentmetadata/add_agent_metadata.go:91-107
• Existing tests explicitly verify optional behavior for each section:
  • libbeat/processors/actions/addagentmetadata/add_agent_metadata_test.go:116-165
• Direct constructor path works with partial config (showing core processor logic is valid), while registry path rejects it (reproduction output above).

[!NOTE]

🔒 Integrity filtering filtered 1 item

Integrity filtering activated and filtered the following item during workflow execution.
This happens when a tool call accesses a resource that does not meet the required integrity or secrecy level of the workflow.

• issue:elastic/beats#unknown (search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)

---

What is this? | From workflow: Bug Hunter

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

• expires on Apr 8, 2026, 11:44 AM UTC