chore(release): v0.1.12

[dray92]

Release v0.1.12 of zxporter, published from the internal services monorepo.

The v0.1.12 tag has already been created and points at this branch's tip — ArgoCD and other tag consumers can use it immediately. This PR is only to advance public main to the released commit for browser convenience.

---

Summary by Gitar

• New collectors and metrics:
  • Added SchedulerMetricsCollector to scrape dz-scheduler leader placement metrics
  • Added KedaScalerMetricsCollector to collect KEDA operator scaler metrics
• Network monitoring enhancements:
  • Introduced redmetrics aggregator for service-level RED telemetry via eBPF socket probes
  • Added socket tracing programs and HTTP/1.1 and HTTP/2 decoders

_{This will update automatically on new commits.}

[gitar-bot]

⚠️ Bug: KEDA collector Stop never closes resourceChan, leaking processor goroutine

KedaScalerMetricsCollector.Stop() closes stopCh but never closes resourceChan (keda_scaler_metrics_collector.go:178-189). The manager's processCollectorChannel goroutine drives for resources := range resourceChan (manager.go:453) and only exits when the channel is closed. Since this collector emits directly via sender.SendScalerMetrics and never writes to or closes resourceChan, its processor goroutine blocks forever after Stop — leaking one goroutine on every selective restart (restartCollectors rebuilds the KEDA collector whenever KEDA_METRICS_ENDPOINT changes) and forcing the manager's shutdown to hit its per-collector and 10s wg.Wait() timeouts each time. Unlike ScaledObjectCollector, which closes batchChan so the batcher closes resourceChan, this collector has no batcher. Fix: close resourceChan in Stop (guarded so it runs once), or close it from the Start goroutine's defer when the loop exits.

Close resourceChan alongside stopCh so the manager's channel processor goroutine terminates.:

func (c *KedaScalerMetricsCollector) Stop() error {
	c.mu.Lock()
	defer c.mu.Unlock()

	select {
	case <-c.stopCh:
		// already closed
	default:
		close(c.stopCh)
		// Close the (unused) resource channel so the manager's
		// processCollectorChannel range loop exits instead of leaking.
		close(c.resourceChan)
	}
	return nil
}

• Apply fix

_{Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎}

[gitar-bot]

Code Review ⚠️ Changes requested 0 resolved / 1 findings

Release v0.1.12 of zxporter adds new collectors and network monitoring enhancements, but the KEDA collector's Stop method does not close resourceChan, leaking a processor goroutine on every selective restart and causing shutdown timeouts. Close resourceChan in Stop (guarded for single execution) or in the Start goroutine's defer before merge.

⚠️ Bug: KEDA collector Stop never closes resourceChan, leaking processor goroutine

📄 internal/collector/keda_scaler_metrics_collector.go:178-192

KedaScalerMetricsCollector.Stop() closes stopCh but never closes resourceChan (keda_scaler_metrics_collector.go:178-189). The manager's processCollectorChannel goroutine drives for resources := range resourceChan (manager.go:453) and only exits when the channel is closed. Since this collector emits directly via sender.SendScalerMetrics and never writes to or closes resourceChan, its processor goroutine blocks forever after Stop — leaking one goroutine on every selective restart (restartCollectors rebuilds the KEDA collector whenever KEDA_METRICS_ENDPOINT changes) and forcing the manager's shutdown to hit its per-collector and 10s wg.Wait() timeouts each time. Unlike ScaledObjectCollector, which closes batchChan so the batcher closes resourceChan, this collector has no batcher. Fix: close resourceChan in Stop (guarded so it runs once), or close it from the Start goroutine's defer when the loop exits.

Close resourceChan alongside stopCh so the manager's channel processor goroutine terminates.

func (c *KedaScalerMetricsCollector) Stop() error {
	c.mu.Lock()
	defer c.mu.Unlock()

	select {
	case <-c.stopCh:
		// already closed
	default:
		close(c.stopCh)
		// Close the (unused) resource channel so the manager's
		// processCollectorChannel range loop exits instead of leaking.
		close(c.resourceChan)
	}
	return nil
}

🤖 Prompt for agents

Code Review: Release v0.1.12 of zxporter adds new collectors and network monitoring enhancements, but the KEDA collector's Stop method does not close resourceChan, leaking a processor goroutine on every selective restart and causing shutdown timeouts. Close resourceChan in Stop (guarded for single execution) or in the Start goroutine's defer before merge.

1. ⚠️ Bug: KEDA collector Stop never closes resourceChan, leaking processor goroutine
   Files: internal/collector/keda_scaler_metrics_collector.go:178-192

   KedaScalerMetricsCollector.Stop() closes stopCh but never closes resourceChan (keda_scaler_metrics_collector.go:178-189). The manager's processCollectorChannel goroutine drives `for resources := range resourceChan` (manager.go:453) and only exits when the channel is closed. Since this collector emits directly via sender.SendScalerMetrics and never writes to or closes resourceChan, its processor goroutine blocks forever after Stop — leaking one goroutine on every selective restart (restartCollectors rebuilds the KEDA collector whenever KEDA_METRICS_ENDPOINT changes) and forcing the manager's shutdown to hit its per-collector and 10s wg.Wait() timeouts each time. Unlike ScaledObjectCollector, which closes batchChan so the batcher closes resourceChan, this collector has no batcher. Fix: close resourceChan in Stop (guarded so it runs once), or close it from the Start goroutine's defer when the loop exits.

   Fix (Close resourceChan alongside stopCh so the manager's channel processor goroutine terminates.):
   func (c *KedaScalerMetricsCollector) Stop() error {
   	c.mu.Lock()
   	defer c.mu.Unlock()
   
   	select {
   	case <-c.stopCh:
   		// already closed
   	default:
   		close(c.stopCh)
   		// Close the (unused) resource channel so the manager's
   		// processCollectorChannel range loop exits instead of leaking.
   		close(c.resourceChan)
   	}
   	return nil
   }

_{Was this helpful? React with 👍 / 👎 | Gitar}