fix(outputs.prometheus_client)!: Bind the configured vsock context ID - #19854

Summary

outputs.prometheus_client split the CID off a vsock://2:9273 listen address and threw it away, then called vsock.Listen(port, nil), which binds the context ID of the machine Telegraf runs on. The listener came up on a different CID than the configuration asked for, nothing warned, and a scraper addressing the configured CID never reached it.

This is the same defect #19774 fixed for inputs.socket_listener, and that PR named this plugin as the follow-up: "outputs.prometheus_client has the same vsock.Listen call with its own parsing and is left for a follow-up." That plugin goes through plugins/common/socket; prometheus_client has its own listener, so the fix did not reach it. This completes it.

The change

// The documented address carries no CID (vsock://:9273) and binding the
// local context ID is right for it. An address that does name one had it
// discarded, so the listener came up on this machine's CID instead and a
// scraper addressing the configured one never reached it.
if cidStr == "" {
    return vsock.Listen(uint32(port), nil)
}

cid, err := strconv.ParseUint(cidStr, 10, 32)
if err != nil {
    return nil, fmt.Errorf("failed to parse CID %s: %w", cidStr, err)
}
listener, err := vsock.ListenContextID(uint32(cid), uint32(port), nil)
if err != nil {
    return nil, fmt.Errorf("listening on CID %d failed: %w", cid, err)
}

Error wording matches #19774 so the two plugins fail the same way, and the README gets the same note yours did.

One deliberate difference from #19774

prometheus_client documents the address as listen = "vsock://:9273" — no CID — and for that form binding the local context ID is correct. inputs.socket_listener always carries a CID, so #19774 had no such case and routes everything through ListenContextID.

Doing that here would have broken the documented default, so the empty host keeps using vsock.Listen and only an explicit CID goes to ListenContextID. There is a test pinning that, because it is the part of this change most likely to be undone by someone later making the two plugins "consistent".

Behaviour change

As in #19774, a configuration naming a CID that does not belong to this machine now fails at startup with EADDRNOTAVAIL instead of quietly binding a different one. That is the point — the previous behaviour was unreachable-by-design — but it is a breaking change for anyone who wrote a CID that was never honoured. CHANGELOG entry added under the existing Important Changes section, next to #19774's.

Testing

Four cases in plugins/outputs/prometheus_client/vsock_test.go, in the shape #19774 used:

gofmt is clean, go vet ./plugins/outputs/prometheus_client/ passes, and go test ./plugins/outputs/prometheus_client/... -count=1 is green: every pre-existing test passes, the non-numeric case passes, and the three that need a vsock-capable host skip.

The skip guard is tighter than #19774's, for a reason I hit

I tried to actually run the binding assertions rather than assume them, in a privileged Linux container with /dev/vsock present. vsock.ContextID() succeeds there and returns 4294967295 — VMADDR_CID_ANY, the wildcard — because Docker Desktop's VM has no guest transport. A guard on the error alone does not fire, and the bind then fails:

listening on CID 4294967295 failed: listen vsock vm(4294967295):9273: socket: function not implemented

That is not specific to my tests. Your merged test fails the same way in the same container:

=== RUN   TestVsockAddressParsing
    socket_test.go:936: listening on CID 4294967295 failed:
        listen vsock vm(4294967295):8790: socket: function not implemented
--- FAIL: TestVsockAddressParsing
--- PASS: TestVsockForeignContextID

So these tests skip through requireVsock, which also skips when the reported context ID is the wildcard. I have observed the skip path firing; the non-skip path is a uint32 comparison, and a real guest or host CID is never 0xffffffff.

plugins/common/socket/socket_test.go has the same gap. I did not touch it — it is not what this PR is about and I would rather you decide — but say the word and I will send the same two-line guard there.

What that leaves unverified

The two positive binding assertions did not execute anywhere I have access to, so the claim that ListenContextID binds the CID you give it rests on the same upstream contract #19774 already relies on, not on a run I can show you. go test ./plugins/outputs/prometheus_client/ -run Vsock -v on a vsock-capable guest would turn those two skips into real coverage.

Checklist

• No AI generated code was used in this PR
• AI generated code used in this PR follows the InfluxData Policy on AI-Generated Code Contributions

Related issues

resolves #19775