On first load should we just not show it until we auto-select? I think that would look better than the flicker.

@kylecarbs The flicker takes as long as the slowest proxy. If the slowest proxy is 2s, that feels like a long time to not be able to determine what proxy to use? Idk how the other FE components would react to a undefined or null proxy selected.

Tbh though, I don't think the flicker is that huge of a deal. It will only happen the first time you authenticate and load the page. Then we save the choice to local storage, and it never changes (unless you select something else).

So the flicker happens once per user per device, and then never again. 🤷

This could give you suboptimal results because AFAIK, the latency measurement is only browser-to-proxy and doesn't include proxy-to-workspace.

Imagine that you have workspaces and proxies in California and Maine. A Colorado user would always select the California proxy, even if the workspace is in Maine.

Another interesting behavior is "auto selected proxy will not update again once set". I'd asssume if we have forward deployed engineers who travel to work with customers they'd need to select the proxy either way.

Could there be a softer way to solve this? When you open the dashboard you get a "notification" or another UI indicator "We've detected a proxy with lower latency. Do you want to switch?"

@spikecurtis

This could give you suboptimal results because AFAIK, the latency measurement is only browser-to-proxy and doesn't include proxy-to-workspace.

Imagine that you have workspaces and proxies in California and Maine. A Colorado user would always select the California proxy, even if the workspace is in Maine.

This is true. Workspace -> Proxy latency would be a better metric, but of course that would be different for different workspaces.

It is only suboptimal if a user is between a workspace and a proxy geographically.

The user in Virginia here always selects the proxy in the north east. But for them, that proxy is the opposite direction as for example the WorkspaceCentral workspace.

The Cali user however, the Cali proxy is pretty much always optimal.

In practice, since we can only select 1 workspace per user, it feels like selecting the closest proxy to the user is going to be the most correct without knowing more information.

Regardless though, we have proxies today and we display latency of the user -> proxy. It does not make sense to our users that the default proxy selected has nothing to do with the latency presented.

@ibetitsmike

Another interesting behavior is "auto selected proxy will not update again once set". I'd asssume if we have forward deployed engineers who travel to work with customers they'd need to select the proxy either way.

Could there be a softer way to solve this? When you open the dashboard you get a "notification" or another UI indicator "We've detected a proxy with lower latency. Do you want to switch?"

We actually had a naive implementation of this originally: #8137

The issue is the latencies presented are not very consistent, and can easily "wiggle" +/-40ms. If you lived in US central, and you had a proxy on US east and US west. You could get this notification every page load as each coast can be better on any given ping.

This inconsistency is why we disabled auto selecting proxies, because it was changing quite frequently for some users. And this changes the links of your apps, so it's not transparent to the user.

This solution tries to find a balance between auto selecting and manual switching. We only auto select on first login (per browser, as we save to local storage). Then we let the user control it.

The behavior today is we default to the primary Coderd, then let the user control it.

So it's really just a minor QoL for first time Coder users.

@ibetitsmike @spikecurtis @kylecarbs are any of your comments blocking?

mine is not blocking

@Emyrk not blocking too

not blocking