Skip to content

web-deploy Focus Page Crash + WSL Interop Fix

Section titled “web-deploy Focus Page Crash + WSL Interop Fix”

1. ID g / ID f (mBR Focus, SDC Focus) crashed the whole app on deploy

web-deploy’s interactive menu assigns letter IDs alphabetically from config.yaml (a=kb-business, b=kb-mbr, c=template, d=mbr-site, e=ts-site, f=sdc-focus, g=mbr-focus). ID g and ID f are the only two projects that deploy via external_deploy_script (FTP) rather than the standard script/local_build_script path — meaning they skip run_task()’s nvm/PATH setup and call pnpm run build directly, relying on inherited shell PATH.

When launched from the Windows desktop shortcut (wsl -- /home/ta/.local/bin/web-deploy), that’s a non-interactive bash -c invocation that never sources ~/.bashrc, so pnpm/nvm are never on PATH. The build raised an uncaught FileNotFoundError, which propagated as an uncaught CalledProcessError in web_deploy.py, crashing the whole app with a traceback — matching “window disappears before I can screenshot.”

Reproduced with env -i HOME="$HOME" PATH="/usr/bin:/bin" python3 focus-deploy/deploy_mbr_focus.pyFileNotFoundError: 'pnpm'.

Fix:

  • Added focus-deploy/build_env.py — shared run_pnpm_build() that sources nvm and builds PATH explicitly, mirroring run_task()
  • deploy_mbr_focus.py / deploy_sdc_focus.py now use it instead of calling pnpm directly
  • web_deploy.py’s execute_deployment() now catches CalledProcessError on the FTP dispatch path and fails gracefully instead of crashing the whole app

Verified live: web-deploy sdc-focus online and web-deploy mbr-focus online both build + FTP-deploy successfully; confirmed via curl -sI (200, fresh last-modified) and via Talbot’s screenshot of the real desktop-shortcut run.

2. Auto-open browser stopped working (regression, unrelated to the above)

/etc/binfmt.d/WSLInterop.conf existed but was empty. This WSL distro now boots with systemd=true; under systemd, WSL→Windows .exe interop (needed for open_browser() to launch powershell.exe/cmd.exe from inside WSL) is registered via this binfmt.d drop-in instead of automatically by WSL’s legacy init. Blank file → systemd-binfmt.service reports success but registers nothing → .exe calls from WSL fail → open_browser() correctly fell back to its “WSL interop unavailable” message.

Fix (Talbot ran, requires sudo):

Terminal window
echo ":WSLInterop:M::MZ::/init:PF" | sudo tee /etc/binfmt.d/WSLInterop.conf && sudo systemctl restart systemd-binfmt

Confirmed: cat /proc/sys/fs/binfmt_misc/WSLInteropenabled; re-tested deploy, browser auto-opens again.

  • ~/utils/web/web-deploy/focus-deploy/build_env.py — new, shared PATH/nvm setup helper
  • ~/utils/web/web-deploy/focus-deploy/deploy_mbr_focus.py — uses run_pnpm_build()
  • ~/utils/web/web-deploy/focus-deploy/deploy_sdc_focus.py — uses run_pnpm_build()
  • ~/utils/web/web-deploy/web_deploy.py — graceful failure on FTP deploy CalledProcessError
  • /etc/binfmt.d/WSLInterop.conf (machine config, not repo) — populated with WSLInterop registration
  • external_deploy_script projects bypass run_task()’s PATH setup entirely. Any new FTP-based deploy project needs to either go through run_task() or use a build helper like build_env.py — don’t call pnpm/node/etc. directly via bare subprocess.run.
  • WSL + systemd: /etc/binfmt.d/WSLInterop.conf can exist but be empty, which fails silently (systemctl status systemd-binfmt reports success). If any WSL→Windows .exe interop breaks after a WSL update, check this file’s actual contents, not just its existence.
  • Manually source-ing a CRLF .env file in bash leaves a trailing \r on the last var per line, which broke FTP DNS resolution during debugging (red herring — the app’s own load_dotenv() handles CRLF fine). Don’t source .env directly in bash for this project; let the app load it.