bvandeusen 11538095be fix(net): validate hop range before checking availability — #2453 ...

TestSetHops_RejectsOutOfRange caught a real ordering bug in code I wrote in
the same commit: the nil-pool guard sat ahead of the range check, so
SetHops(-1) on a service with no pool returned "network settings unavailable"
instead of ErrHopsOutOfRange.

Range first is correct, and the distinction is user-visible rather than
cosmetic: the argument is invalid regardless of whether the database is
reachable, and admin_network.go maps ErrHopsOutOfRange to 400 while anything
else becomes 500. The old order blamed the server for the caller's input.

Note this is the first failure in this sequence that wasn't a missed call
site — vet and golangci-lint both passed, and a test asserting a specific
sentinel error found it. Worth the extra assertion; `err != nil` would have
passed happily.

2026-08-05 10:27:10 -04:00

..

service_test.go

feat(net): trusted-proxy depth so real client IPs survive a proxy — #2453

2026-08-05 10:07:43 -04:00

service.go

fix(net): validate hop range before checking availability — #2453

2026-08-05 10:27:10 -04:00