Management warns at every start about peer update interval variables that are optional and undocumented

[chad-loder]

Before posting

• I searched existing discussions and issues, including closed ones, and checked the relevant docs.
• I believe this is a product bug rather than a configuration or setup question.
• I can reproduce this issue, or for intermittent issues I've included trigger, frequency, and timing details below.
• I removed or anonymized sensitive data from logs, screenshots, and configuration.

Affected area

Management service / API, Self-hosting / Deployment

Deployment type

Self-hosted - advanced/custom deployment

Operating system or environment

Linux, Docker

NetBird version and upgrade status

• Management: 0.77.0
• Upgrade status: not yet on 0.80.0; the code path is unchanged on main (management/internals/controllers/network_map/controller/controller.go, StartWarmup).

Did this work before?

Not sure

Regression details

No response

Summary

StartWarmup parses NB_PEER_UPDATE_INTERVAL_MS and NB_PEER_UPDATE_STARTUP_PERIOD_S with strconv.Atoi and logs a parse warning whenever that fails, including when the variable is simply not set. Neither variable appears in the docs or the setup files, so a default deployment logs a warning on every start for a setting it has no reason to know about.

Current behavior

• NB_PEER_UPDATE_INTERVAL_MS unset: failed to parse peer update interval, using default value 1ms: strconv.Atoi: parsing "": invalid syntax, and the update buffer stays at 1 ms.
• NB_PEER_UPDATE_INTERVAL_MS set (for example to 1000) and NB_PEER_UPDATE_STARTUP_PERIOD_S unset: on every start, failed to parse peer update startup period, using default value 1s: strconv.Atoi: parsing "": invalid syntax (level warning, controller.go:898 in 0.77.0).

Expected behavior

An unset optional variable takes its default without a warning; a warning only when the variable is set to something that does not parse. And the two variables documented for self-hosters, with their defaults (1 ms buffer, 1 s startup period) and what the startup period does (the buffer starts at ten times the interval and drops to the interval once the period ends).

Steps to reproduce

1. Start management with neither variable set: the interval warning appears once per start.
2. Start management with only NB_PEER_UPDATE_INTERVAL_MS=1000 set: the startup period warning appears once per start.

Environment and topology

Management in its own container with a PostgreSQL store. The behavior does not depend on topology.

Self-hosted details, if available

No response

Logs, status output, or debug evidence

The two warning lines above, from the management log (JSON format).

Related issues or discussions

None found.

Possible change

If the direction is agreed: in StartWarmup, read each variable with os.LookupEnv and warn only when it is present and fails to parse; no other behavior change. I'd be happy to put up a PR for this, along with a docs note for the two variables, once the approach is accepted.

[hippi345]

Confirmed on main. StartWarmup does strconv.Atoi(os.Getenv(...)) with no presence check, so an unset variable is parsed as "" and warns. The warning is harmless. Current behavior, straight from the code:

• NB_PEER_UPDATE_INTERVAL_MS unset → buffer is 1 ms, warning logged, and the startup-period variable is never read.
• set to N → buffer starts at 10×N ms, then a goroutine sleeps NB_PEER_UPDATE_STARTUP_PERIOD_S seconds (default 1, and it warns if unset) and drops the buffer to N ms.

If you just want clean logs now, set both: NB_PEER_UPDATE_INTERVAL_MS=1 and NB_PEER_UPDATE_STARTUP_PERIOD_S=1. That gives 10 ms for the first second and then 1 ms, which is practically the same as the default. The os.LookupEnv change you proposed is the right fix.