🐛 Cloudflared ignores the initial version of a remote config

[ArielPrevu3D]

Describe the bug Cloudflared ignores the first version of the remote config.

https://github.com/cloudflare/cloudflared/blob/master/orchestration/orchestrator.go#L43

This comment indicates that remote config versions are always superior to 0, yet a remote configs created via the API starts with version 0.

To Reproduce

1. Create a Cloudflare Tunnel via the API
2. Create a Cloudflare Tunnel remote configuration via the API
3. Run the tunnel with a config file and a credential file

Cloudflared then uses the config file and ignores the remote config.

Expected behavior The initial version of a remote config should be applied by cloudflared.

Environment and versions

• OS: Windows Pro 11 21H2 1000.22000.739.0
• Architecture: x86-64
• Version: 2022.6.1

Log {"level":"debug","current_version":1,"received_version":1,"time":"2022-06-16T14:06:20Z","message":"Current version is equal or newer than received version"}

Additional context Maybe the currentVersion in the Orchestrator should be initialized with -1. Or maybe the logic should differentiate between local and remote configs more explicitly to ensure that remote configs have precedence. Or maybe the configuration created by the API should start at version 1 when using PUT /configurations.

The same thing happens if you create a tunnel via the Cloudflare Teams UI and you do not set a configuration. The configuration exists with version 0. However, this poses no issue since the config is null.

Current workaround is to push an update to the remote config right after creating it. The remote config version is then incremented from 0 to 1.

[nemosupremo]

I believe I am also seeing this issue (although can't confirm because I "fixed" it by executing the above workaround before I had the foresight to enable debug logging).

In our case we aren't using a local config at all:

Jul 25 22:28:53 livereach cloudflared[3080]: 2022-07-25T22:28:53Z INF Cannot determine default configuration path. No file [config.yml config.yaml] in [~/.cloudflared ~/.cloudflare-warp ~/cloudflare-warp /etc/cloudflared /usr/local/etc/cloudflared]
Jul 25 22:28:53 livereach cloudflared[3080]: 2022-07-25T22:28:53Z INF Version 2022.7.1

[jimbojsb]

+1 for this. When running cloudflared in a docker container with no local config at all, the only way it correctly obeys the API-created config is if you create the tunnel, run the tunnel and then after the tunnel is up, add the config, so that it gets it as an update.

[ph00lt0]

I am experiencing this exact issue on a Ubuntu server, no docker. Didn't find a workaround yet;

[asychev]

I do believe we see the same issue. If I create a tunnel initially via dashboard with tunnel config and then run tunnel with token only (cloudflared tunnel run --token) - cloudflared don't get config (no Updated to new configuration config in the logs).

We create tunnel initially with terraform and it maybe different from how tunnel created via UI (it might create empty zero config first, then update it, this way config becomes 1 and cloudflared properly pick it up).

[asychev]

@sudarshan-reddy Any chance this can get an attention?