microsoft / microsoft/dev-tunnels
devtunnel create routing flaps between near-equidistant clusters, silently creating cross-cluster duplicates
@plequere-ms is already working on this.
Since Jun 9, 2026.
- Dominant language
- C#
- Stars
- 508
- Forks
- 52
- Avg merge
- 20h 6m
- Merged PRs (30d)
- 7
Description
Summary
devtunnel create <id> chooses the cluster by nearest-by-latency. On a host roughly
equidistant between two clusters, the "nearest" pick is unstable between runs, so repeated
create of the same tunnel id lands it in different clusters on different runs —
producing two distinct tunnels that share one id (id is unique per cluster). Because the
public URL encodes the cluster (https://<id>-<port>.<cluster>.devtunnels.ms), the URL
also changes when the cluster flips, silently invalidating anything that persisted it
(webhooks, OIDC redirect URIs).
Repro
On a host where two clusters report near-identical ping (e.g. a box in Helsinki sees
uks1 and euw within a few ms — devtunnel clusters --ping):
devtunnel create my-tunnel # run 1 -> my-tunnel.uks1
devtunnel delete my-tunnel.uks1
devtunnel create my-tunnel # run 2, minutes later -> my-tunnel.euw (nearest flipped)
Without an explicit delete, re-running create/host from tooling across the flip leaves
both my-tunnel.uks1 and my-tunnel.euw present.
Why it matters
- Unstable public URL. A URL registered with an external service (Azure Bot Service
messaging endpoint, OAuth redirect, webhook) breaks when the cluster flips, with nothing
in the caller's config having changed. - Silent duplicates. Bare-name operations on a duplicated id then behave ambiguously —
a host can attach to one cluster while a lookup resolves the other. - This is the root cause behind microsoft/aspire#14111,
where .NET Aspire's DevTunnels integration (which shells bare-namecreate) inherits the
flap.
Suggestions (any one would resolve it)
- Make a tunnel id sticky to its cluster: once
<id>exists in some cluster, a later
barecreate <id>reuses/targets that cluster instead of re-running nearest-routing. - Honour the persisted default cluster (
devtunnel set/CurrentClusterId) oncreate. - Add hysteresis to nearest-cluster selection so a near-tie doesn't flip run to run.
(A documented create-time cluster override — --service-uri, see the companion docs issue
microsoft/dev-tunnels#643 — lets callers opt out, but the default behaviour is still the
trap.)
Environment
- devtunnel CLI
1.0.1824+9e602bae78, Linux x64, Microsoft Entra ID auth.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.