fix(runner): gracefully shutdown HTTP servers

[linkdata]

Summary

• track pprof and metrics server goroutines in the runner WaitGroup
• gracefully shut down HTTP servers before waiting for worker exit
• leave dnstap ReadInto fire-and-forget because the library provides no stop hook

Tests

• go test ./pkg/runner ./...

[coderabbitai]

Warning

Rate limit exceeded

@linkdata has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 59 minutes and 29 seconds before requesting another review.

To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 2223026d-1384-4180-8e0b-7bd59ead9f81

📥 Commits

Reviewing files that changed from the base of the PR and between b615285 and bfb63ca.

📒 Files selected for processing (1)

• pkg/runner/runner.go

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Review rate limit: 0/1 reviews remaining, refill in 59 minutes and 29 seconds.}

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[linkdata]

Additional context from comment files

These notes were split from the local markdown comment files and attached here because they describe this PR's change.

DNStap Reader Goroutine Limitation

• Note: The dnstap reader goroutine (dti.ReadInto(edm.inputChannel)) is started fire-and-forget without WaitGroup tracking. An earlier attempt to track it in wg and close inputChannel on shutdown caused SIGINT to hang because the upstream golang-dnstap library does not expose a stop/close mechanism for ReadInto — the goroutine blocks reading from the socket indefinitely. Closing inputChannel from Run() would also race with ReadInto sending and panic.
• Impact: The ReadInto goroutine leaks on shutdown, but the OS reclaims it on process exit.
• Status: Documented as an upstream library limitation. Fixing this properly would require either a patch to golang-dnstap to support cancellation, or closing the underlying listener from outside, which the current FrameStreamSockInput does not expose.

HTTP Servers (pprof and metrics) Not Synchronized or Gracefully Shut Down

• Bug: The pprof and metrics HTTP servers (lines 1269-1272 and 1285-1288) were started as goroutines without WaitGroup tracking. Neither server received graceful shutdown signals; both ListenAndServe() blocks indefinitely. When wg.Wait() completed, they were still running.
• Impact: Unclean HTTP server shutdown; potential connection leaks; incomplete request handling; goroutines forced to terminate abruptly on process exit.
• Fix: (1) Wrapped both servers in tracked goroutines with wg.Add(1) and defer wg.Done(), handling http.ErrServerClosed as expected error. (2) Added graceful Shutdown(ctx) calls with 5-second timeout before wg.Wait().
• Reasoning: HTTP servers need explicit graceful shutdown to drain pending requests and close connections cleanly; all goroutines should be tracked for proper ordering.
• Tests: Verified by running full test suite and checking that shutdown completes without errors.