Summary

While working with remote write configurations, I noticed that queue_config parameters had zero validation. This meant users could accidentally set max_samples_per_send: 0 (or other invalid combinations) and Prometheus would accept the config silently—only to panic at runtime with an integer divide-by-zero error when the queue manager started.

The panic happens in newQueue() when calculating capacity / batchSize with batchSize=0. Beyond the crash, other misconfigurations like min_shards > max_shards or max_backoff < min_backoff were also silently accepted, leading to undefined runtime behavior.

This PR adds proper validation to catch these issues at config load time.

Fix

Added QueueConfig.Validate() method in config/config.go that checks:

• All numeric fields are positive (max_shards, min_shards, max_samples_per_send, capacity)
• min_shards ≤ max_shards
• max_backoff ≥ min_backoff

The validation is called from RemoteWriteConfig.UnmarshalYAML() so invalid configs fail fast during startup.

Key changes:

config/config.go — Added validation method (~20 LOC):

func (c *QueueConfig) Validate() error {
    if c.MaxSamplesPerSend <= 0 {
        return errors.New("remote write queue max_samples_per_send must be positive")
    }
    if c.Capacity <= 0 {
        return errors.New("remote write queue capacity must be positive")
    }
    // ... additional checks for shards and backoff
    if c.MinShards > c.MaxShards {
        return errors.New("remote write queue min_shards must not be greater than max_shards")
    }
    return nil
}

Also added 3 test cases in config/config_test.go and corresponding bad config YAML files in config/testdata/ covering each validation path.

Does this PR introduce a user-facing change?

[BUGFIX] Config: Validate remote_write queue_config fields at load time to prevent runtime panic and silent misconfiguration.