Problem
The coder_app healthcheck of the vscode-web module points at /healthz:
healthcheck_url = var.subdomain ? "http://localhost:${var.port}/healthz" : "http://localhost:${var.port}${local.server_base_path}/healthz"
Microsoft's standalone VS Code web server (the vscode-server-linux-*-web build this module downloads and runs via serve-local) has no /healthz route. Against the current stable build (1.124.2):
$ curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:13338/healthz
404
$ curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:13338/version
200
$ curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:13338/
200
/healthz presumably carried over from the code-server module — code-server really does expose /healthz, but the Microsoft server does not.
Impact
Mostly correctness/clarity rather than a visible breakage: the agent treats any response below 500 as healthy (agent/apphealth.go), so the 404 never shows up as an unhealthy app. But the check is effectively only "does anything answer HTTP on that port", and the URL misleads anyone copying the module's pattern into their own templates or customizations.coder.apps (where I ran into it: coder/devcontainer-features#22).
Suggested fix
Probe /version instead, which the web server answers with 200 in both the subdomain and path-based cases. I'll send a PR.
Problem
The
coder_apphealthcheck of the vscode-web module points at/healthz:Microsoft's standalone VS Code web server (the
vscode-server-linux-*-webbuild this module downloads and runs viaserve-local) has no/healthzroute. Against the current stable build (1.124.2):/healthzpresumably carried over from the code-server module — code-server really does expose/healthz, but the Microsoft server does not.Impact
Mostly correctness/clarity rather than a visible breakage: the agent treats any response below 500 as healthy (
agent/apphealth.go), so the 404 never shows up as an unhealthy app. But the check is effectively only "does anything answer HTTP on that port", and the URL misleads anyone copying the module's pattern into their own templates orcustomizations.coder.apps(where I ran into it: coder/devcontainer-features#22).Suggested fix
Probe
/versioninstead, which the web server answers with 200 in both the subdomain and path-based cases. I'll send a PR.