Fix event batcher flush span race

[pingsutw]

Summary

Fixes a timing race in eventBatcher.flush telemetry recording. The flush span was ended via defer, after callers were released through their done channel, so Record could return before the span recorder observed the ended eventBatcher.flush span.

This makes the span end explicit before notifying callers, keeping the synchronous Record contract aligned with the test expectation.

Root cause

TestEventBatcher_FlushSpanLinksCallers inspects ended spans immediately after Record returns. Because span.End() ran in a deferred call after writing to done, scheduler timing could let the test resume before the span was ended, producing zero flush spans.

Validation

• go test ./executor/pkg/controller -run TestEventBatcher_FlushSpanLinksCallers -count=100
• go test -race -coverprofile=coverage.out -covermode=atomic ./executor/pkg/controller
• go test -race -coverprofile=coverage.out -covermode=atomic ./executor/...
• go test ./executor/pkg/controller -run TestEventBatcher_FlushSpanLinksCallers -count=20

[Copilot]

Pull request overview

Fixes a timing race in eventBatcher.flush span lifecycle by ensuring the flush span is ended before unblocking Record callers, aligning the synchronous Record contract with telemetry expectations.

Changes:

• Removes deferred span ending in flush and ends the span explicitly after Record completes.
• Ensures callers are notified (via done) only after the flush span has been ended.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.