Files
meshcore-analyzer/cmd
efitenandClaude Opus 5 5efe61eef2 fix(ingestor): set an explicit MQTT ClientID per source (#2013) (#2016)
## What

`buildMQTTOpts` (`cmd/ingestor/main.go:591`) never called `SetClientID`,
so with paho.mqtt.golang v1.5.0 every ingestor connected with a
zero-length ClientID and `CleanSession=true`. The session identity then
depended on the broker.

This PR:

- adds an optional `clientId` per `mqttSources` entry
(`cmd/ingestor/config.go:29`)
- when unset, uses `corescope-<name>-<6 hex chars>`
(`cmd/ingestor/main.go:653`). The name is reduced to `[0-9A-Za-z-]`,
with the broker host as fallback when the name is empty. The suffix
comes from `crypto/rand` and changes on every ingestor start.
- sets the ID once per source in `buildMQTTOpts`
(`cmd/ingestor/main.go:616`). paho copies the options into the client
and reuses them for every reconnect, and the watchdog force-reconnect
reuses the same client, so the ID is stable for the life of the process.
- logs the ID on connect: `MQTT [tag] connected to <broker> as client
<id>` (`cmd/ingestor/main.go:150`)
- documents the key in `config.example.json:210` as a
`_comment_clientId` entry rather than a value, because
`docker/entrypoint.sh:6` copies that file as a live config and a literal
value would give every default deployment the same ID. Also listed in
`cmd/ingestor/README.md:94`.

## paho behaviour

- No client-side length limit. `SetClientID` only stores the value; the
65535 check in `packets/connect.go:156` is in `Validate()`, which the
client never calls.
- The default ID is longer than the MQTT 3.1 limit of 23 characters for
most source names. paho falls back to MQTT 3.1 after any refused CONNACK
when no protocol version is set (`client.go:412`), so on a broker that
refuses the first 3.1.1 attempt, the retry may hit that limit. I did not
cap the length because paho does not require it and the 3.1.1 path
accepts it (see below).

## Tests

`cmd/ingestor/mqtt_opts_test.go:53-107`:

- default ID is non-empty, has the sanitized name prefix, and contains
only `[0-9A-Za-z-]`
- broker host is used when the name is empty
- configured `clientId` is used verbatim
- two unconfigured sources with the same name get different IDs
- the client built from the options reports the same ID

Mutation checks: removing the random bytes fails the "different IDs"
test; removing sanitization fails the prefix and character-set tests.

`go test ./...` in `cmd/ingestor` passes except
`TestWriteStatsAtomic_SymlinkAtDestIsReplaced`, which fails locally on
Windows for a symlink privilege reason. `gofmt` and `go vet` are clean.

## Validation against a real broker

On a staging instance (build `e84d2da6`) connecting to a Mosquitto
bridge:

```
MQTT [lincomatic] connection attempt #1 to tcp://mosquitto-bridge:1883
MQTT [lincomatic] connected to tcp://mosquitto-bridge:1883 as client corescope-lincomatic-71a6eb
MQTT [lincomatic] subscribed to meshcore/#
```

The 27-character default was accepted on the first attempt and packets
kept arriving afterwards.

## Not verified

- Only one broker type (Mosquitto) was tried.
- `-race` was not run locally (no cgo toolchain on the test machine).
- The case where both the source name and the broker host are empty (ID
becomes `corescope-<hex>`) has no test.

Fixes #2013



## Review follow-up (commit `a1d6709e`)

An independent review found no bug in the ID handling, but the tests
covered less than their names said. Changed, tests only
(`cmd/ingestor/mqtt_opts_test.go`):

- `TestBuildMQTTOpts_ClientIDSurvivesReconnects` replaces the old
stability test, which only checked that paho copies the options. Against
a loopback fake broker built on paho's `packets` codec, the first
CONNECT, paho's auto-reconnect after the broker drops the socket, and
the watchdog force-reconnect (`buildForceReconnectFn`) must all carry
the same non-empty ID. It runs in about 0.01 s and passed `-count=30
-cpu 1,2,8`.
- `TestBuildMQTTOpts_ClientIDDefaultShape` asserts full IDs:
`^corescope-local-feed-1-[0-9a-f]{6}$`,
`^corescope-mqtt-example-com-[0-9a-f]{6}$` for the broker host fallback
(no port), and `^corescope-[0-9a-f]{6}$` with neither a name nor a host.
- Mutations now caught: `SetClientID` removed, `u.Host` instead of
`u.Hostname()`, a 1-byte suffix, the name guard dropped, sanitization
removed. The "as client" log line has no test because it is logged from
a closure inside `main()`.

Corrections to the description:

- **Fallback to MQTT 3.1.** paho falls back after any failed handshake
once the socket is open, not only after a refused CONNACK: also a read
error or timeout before any CONNACK, or a first packet that is not a
CONNACK (`client.go:401-416`, `net.go:83-97`). A failed dial does not
trigger it (`client.go:387-391`), and after the first successful connect
the protocol version is locked in (`client.go:422-424`). Without this PR
the 3.1 retry sent an empty ID, which MQTT 3.1 forbids as well, so
nothing gets worse.
- **Broker side.** On the EMQX broker we run, authorization has
per-username and all-client rules and no client-ID rules (checked
through its REST API). Two per-username rules use `${clientid}` in a
topic, but both are publish rules and the ingestor only subscribes, so
no rule can match it. A broker that caps IDs at 23 characters but
accepted the empty ID before would now reject the default ID for source
names of 7 or more characters; I have no evidence such a broker is in
use.
- The "Not verified" item about the empty name and host case no longer
applies.

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-13 19:57:37 +02:00
..