microsoft / microsoft/dev-tunnels

devtunnel create routing flaps between near-equidistant clusters, silently creating cross-cluster duplicates

Open
#642 2 comments 0 reactions 1 assignee View on GitHub

@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-name create) 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
    bare create <id> reuses/targets that cluster instead of re-running nearest-routing.
  • Honour the persisted default cluster (devtunnel set / CurrentClusterId) on create.
  • 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.