fix: return 400 instead of 500 for user-caused process start failures

[hiroTamada]

Summary

• /process/exec and /process/spawn were returning 500 when cmd.Start() failed due to user input (command not found, bad path, permission denied), inflating our 5xx error rate and triggering false backend alerts
• Added isUserCmdError helper that detects exec.ErrNotFound, os.ErrNotExist, and os.ErrPermission — these map to 400 since they're client input errors
• Genuine server-side start failures (EAGAIN, ENOMEM, etc.) still return 500

Test plan

• TestProcessExec_CommandNotFound — verifies exec returns 400 for missing binary
• TestProcessSpawn_CommandNotFound — verifies spawn returns 400 for missing binary
• All existing process tests pass (go test -v -race)

Made with Cursor

---

Note

Low Risk
Low risk: changes only error classification/HTTP status codes for process start failures in /process/exec and /process/spawn, with added coverage to prevent regressions.

Overview
Adjusts /process/exec and /process/spawn to treat common user-caused start failures (e.g., command not found, bad path/permissions, invalid executable) as 400 Bad Request instead of 500, reducing misleading 5xx alerts.

Adds an isUserCmdError helper to centralize this detection and new tests verifying both exec and spawn return 400 for a nonexistent command.

^{Written by Cursor Bugbot for commit 30d1881. This will update automatically on new commits. Configure here.}

[Sayan-]

generally lgtm ^^

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

os.ErrPermission catches server-side EPERM as user error

Medium Severity

errors.Is(err, os.ErrPermission) matches both syscall.EACCES and syscall.EPERM due to Go's Errno.Is mapping. Only EACCES (file permission denied) is a user-input error. EPERM (operation not permitted) can arise from server-side issues — most notably when AsRoot or AsUser sets SysProcAttr.Credential but the server lacks CAP_SETUID/CAP_SETGID. In that case cmd.Start() fails with EPERM, which gets misclassified as a 400 instead of 500, masking a server configuration problem. Using syscall.EACCES directly instead of os.ErrPermission would avoid catching EPERM.

Additional Locations (1)

• server/cmd/api/api/process.go#L116-L120

 

[hiroTamada]

I think 400 is fine for now in this case