Desktop 0.2.1-rc.3 on Windows: startup fails with "desktop welcome: Web authentication failed" after many launches

[txdy831]

Hi — not sure whether this is already a known issue, so apologies in advance if it has been reported before.

I've been using the Windows desktop build (0.2.1-rc.3, nightly channel) on a machine that gets restarted fairly often. After a few dozen launches it stopped opening entirely: double-clicking the icon brings the process up and it exits again immediately, with no window.

The crash log is the same every time:

Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (.../resources/app/lib/main.js)
    at async Object.start (.../main.js)
source: host
phase: startup

Looking at the Electron profile, the cookie store had built up a fair number of entries:

cookies 总数: 71
dsh-auth-*: 71
host 分布: 127.0.0.1 x71

Reading through the startup path, it looks like this might be a small leak that compounds over time:

1. the Host binds a new port on each launch, so ready.url differs every time;
2. authenticateWebHost() mints a dsh-auth-<host-hash> cookie per port, and cookies for ports that are already gone are never removed;
3. connectDesktopWelcome() calls net.fetch(..., { credentials: "include" }), which puts every 127.0.0.1 cookie into a single Cookie header;
4. once that header grows past Node's http.maxHeaderSize (16 KB by default), the request comes back 401, authenticated.ok is false, and startup throws.

Since a failed launch still leaves a new cookie behind, retrying seems to make the next attempt slightly more likely to fail rather than less — which is probably why it felt like a sudden breakage instead of something that crept up.

Removing the stale dsh-auth-* cookies by hand brought startup back, so this isn't blocking me permanently. But a long-lived install would presumably hit it eventually, and the message ("Web authentication failed") points at the network rather than at cookie accumulation, which made it take a while to track down.

If it's helpful, a few possible directions:

• sweep dsh-auth-* before minting a new one (those ports are gone, so the values are stale);
• or overwrite one stable cookie name instead of accumulating per-port ones;
• or give the cookie a short expiry so the set converges on its own;
• and perhaps check the projected Cookie header size before the request, so the failure surfaces as something more diagnosable than "authentication failed".

Happy to share logs, try a build, or provide anything else that would help. Thanks!

[PerryLink]

Yes, this is the cookie one. The 71 dsh-auth-* entries for 127.0.0.1 are the whole story.

packages/client/connection/src/browser-auth.ts:116-118 derives the cookie name from a hash of the authority, and requestAudience (:84) keeps a non-default port in it. The desktop launches the host without a port argument, so a launch that lands on a new port mints a new dsh-auth-<43 chars> name; sessionCookie (:131-140) sets Max-Age and nothing deletes the older ones. Cookies for 127.0.0.1 go to every port on that host, so the jar grows one entry per launch until the request header crosses maxHeaderSize and the welcome request gets 431 — which surfaces as Web authentication failed.

Clearing the dsh-auth-* cookies for 127.0.0.1 restores startup. Reinstalling does not, because the jar lives under Electron's userData, which an in-place update keeps (apps/desktop/README.md:264).

It is still unfixed at f3803c96 (0.2.2-alpha.2): that file is byte-identical to 22ddee3. The fix needs two halves — drop the port from the name, and delete sibling dsh-auth-* cookies on startup so already-poisoned jars recover by themselves.

Source read at f3803c96; I did not run a desktop build.