web-deploy Focus Page Crash + WSL Interop Fix
Section titled “web-deploy Focus Page Crash + WSL Interop Fix”What was fixed
Section titled “What was fixed”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.py → FileNotFoundError: 'pnpm'.
Fix:
- Added
focus-deploy/build_env.py— sharedrun_pnpm_build()that sources nvm and buildsPATHexplicitly, mirroringrun_task() deploy_mbr_focus.py/deploy_sdc_focus.pynow use it instead of callingpnpmdirectlyweb_deploy.py’sexecute_deployment()now catchesCalledProcessErroron 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):
echo ":WSLInterop:M::MZ::/init:PF" | sudo tee /etc/binfmt.d/WSLInterop.conf && sudo systemctl restart systemd-binfmtConfirmed: cat /proc/sys/fs/binfmt_misc/WSLInterop → enabled; re-tested deploy, browser auto-opens again.
Files changed
Section titled “Files changed”~/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— usesrun_pnpm_build()~/utils/web/web-deploy/focus-deploy/deploy_sdc_focus.py— usesrun_pnpm_build()~/utils/web/web-deploy/web_deploy.py— graceful failure on FTP deployCalledProcessError/etc/binfmt.d/WSLInterop.conf(machine config, not repo) — populated with WSLInterop registration
Key gotchas
Section titled “Key gotchas”external_deploy_scriptprojects bypassrun_task()’s PATH setup entirely. Any new FTP-based deploy project needs to either go throughrun_task()or use a build helper likebuild_env.py— don’t callpnpm/node/etc. directly via baresubprocess.run.- WSL + systemd:
/etc/binfmt.d/WSLInterop.confcan exist but be empty, which fails silently (systemctl status systemd-binfmtreports success). If any WSL→Windows.exeinterop breaks after a WSL update, check this file’s actual contents, not just its existence. - Manually
source-ing a CRLF.envfile in bash leaves a trailing\ron the last var per line, which broke FTP DNS resolution during debugging (red herring — the app’s ownload_dotenv()handles CRLF fine). Don’tsource .envdirectly in bash for this project; let the app load it.