pingdotgg / pingdotgg/t3code

[Bug]: Disabling the WSL backend in a running desktop does not stop it; supervisor respawns it on exit

Open
#12,642 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

accepted bug via-triage
Dominant language
TypeScript
Stars
23k
Forks
5.9k
Avg merge
11h 14m
Merged PRs (30d)
357

Description

Before submitting
  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.
Area

apps/desktop

Steps to reproduce
  1. Windows desktop app with the WSL backend enabled and running (desktop.backendInstance.start {"id":"wsl:Ubuntu"} in desktop.trace.ndjson).
  2. In settings, disable the WSL backend. The trace logs desktop.settings.writeSettings, desktop.wslBackend.reconcile with event tearing down WSL backend, desktop.ipc.wsl.setEnabled.
  3. Inside WSL: pgrep -fa wsl-runtime. The ~/.t3/wsl-runtime/sha256-…/t3 --bootstrap-fd 0 process is still running and still listening.
  4. Kill that process inside WSL.
Expected behavior

Step 2 stops the WSL runtime process and unregisters the instance from the backend pool. Nothing respawns it while the setting is off.

Actual behavior

The process survives the teardown (checked 90 seconds later). When it is killed, the pool supervisor restarts it:

desktop.backendInstance.scheduleRestartFiber  "backend exited unexpectedly; restart scheduled"
desktop.backendInstance.start {"id":"wsl:Ubuntu"}

This happened twice in a row (00:19:12 and 00:20:25). The setting itself persisted (desktop-settings.json no longer contains wslBackendEnabled), and a full app restart does not start the WSL backend, so only the live reconcile path is affected.

Side effect: the respawned WSL runtime shares ~/.t3/userdata with a t3 service install server in the same distro, and each one re-registers its own port with the relay on startup (last writer wins), which repeatedly broke T3 Connect for the Linux environment.

Impact

Degrades the experience (needs a full app restart to actually disable WSL; breaks remote access when combined with a WSL service).

Version or commit

Desktop 0.0.42 (Windows).

Environment

Windows 11, WSL2 Ubuntu (networkingMode=mirrored), t3 service install inside the same distro.

Logs or stack traces
00:17:14 desktop.settings.writeSettings
00:17:14 desktop.wslBackend.reconcile  ["tearing down WSL backend"]
00:17:14 desktop.ipc.wsl.setEnabled
00:19:12 desktop.backendInstance.scheduleRestartFiber ["backend exited unexpectedly; restart scheduled"]
00:19:12 desktop.backendInstance.start {"id": "wsl:Ubuntu"}
00:20:25 desktop.backendInstance.scheduleRestartFiber ["backend exited unexpectedly; restart scheduled"]
00:20:26 desktop.backendInstance.start {"id": "wsl:Ubuntu"}
Workaround

Restart the desktop app after disabling the WSL backend.

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.

Research direction

Start in apps/desktop by tracing desktop.wslBackend.reconcile and desktop.ipc.wsl.setEnabled, then follow desktop.backendInstance.scheduleRestartFiber and desktop.backendInstance.start. Reproduce the live disable flow with a running wsl:Ubuntu backend and inspect the trace. Done means disabling WSL stops the runtime, unregisters the instance, and prevents supervisor respawns without restarting the app.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend, desktop
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
65/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.