TestProcessBundledEvents in pkg/collector/corechecks/cluster/kubeapi never completes. It runs until the Go test timeout and fails the whole package, so kubeapi cannot go green.
Reproduce
go test -count=1 -timeout 90s -tags "kubeapiserver test" \
-run TestProcessBundledEvents ./pkg/collector/corechecks/cluster/kubeapi/...
panic: test timed out after 1m30s
FAIL github.com/DataDog/datadog-agent/pkg/collector/corechecks/cluster/kubeapi 90.037s
At the default 10m timeout it burns the full ten minutes before failing.
What it looks like
The dumped goroutines are parked in select inside the aggregator — timeSamplerWorker.run (pkg/aggregator/time_sampler_worker.go:103) and BufferedAggregator.run (pkg/aggregator/aggregator.go:800), both created by AgentDemultiplexer.run. Consistent with the test waiting on something the demultiplexer never delivers, rather than a slow assertion.
The preceding test in the file, TestProcessPodEvents, passes in ~1s.
Scope
Reproduces at 55dff4f0de on the STAC-25490-otel-spike branch. Not introduced by the provenance-tag work — verified by running it in a clean worktree at that commit.
I have not checked whether it also hangs on master. The file was last touched by the 7.71.2 → 7.78.2 upstream merge (60fa584922), which is the most likely origin either way.
Worth knowing because it masks real failures: anyone running the kubeapi package to check their own change gets a 10-minute wait and a FAIL that has nothing to do with them.
TestProcessBundledEventsinpkg/collector/corechecks/cluster/kubeapinever completes. It runs until the Go test timeout and fails the whole package, sokubeapicannot go green.Reproduce
At the default 10m timeout it burns the full ten minutes before failing.
What it looks like
The dumped goroutines are parked in
selectinside the aggregator —timeSamplerWorker.run(pkg/aggregator/time_sampler_worker.go:103) andBufferedAggregator.run(pkg/aggregator/aggregator.go:800), both created byAgentDemultiplexer.run. Consistent with the test waiting on something the demultiplexer never delivers, rather than a slow assertion.The preceding test in the file,
TestProcessPodEvents, passes in ~1s.Scope
Reproduces at
55dff4f0deon theSTAC-25490-otel-spikebranch. Not introduced by the provenance-tag work — verified by running it in a clean worktree at that commit.I have not checked whether it also hangs on
master. The file was last touched by the7.71.2→7.78.2upstream merge (60fa584922), which is the most likely origin either way.Worth knowing because it masks real failures: anyone running the
kubeapipackage to check their own change gets a 10-minute wait and aFAILthat has nothing to do with them.