[masnwilliams]

Summary

When Neko can't set a screen configuration, it returns 422 (cannot set screen size). kernel-images passes that back as a 500 from both PATCH /display and /configure, so callers can't tell "this size isn't supported" apart from a server fault. The control plane only turns a 4xx from the VM into a client error; a 500 gets treated as a broken instance, retried on other instances, and then reported as a generic 500.

Change

• nekoclient.ScreenConfigurationChange wraps a 422 in the new ErrScreenConfigurationRejected. Other non-2xx statuses are unchanged.
• PATCH /display (Xorg path) and the /configure display step applied while Chromium is stopped return 400 the display cannot be set to WxH at R Hz for that error. The live /configure path goes through patchDisplayLocked, so it gets the 400 as well. Every other failure is still a 500.

This doesn't make more sizes work. The root cause, generated modes that X lists at one Hz below the requested rate, is fixed in kernel/neko#31. With that fix in, the remaining 422s are sizes the X server can't set at all, for example anything below 64x64.

Testing

• Unit tests:
  • TestScreenConfigurationChangeStatus covers 200, 422 and 500 from a fake Neko.
  • TestPatchDisplayNekoRejection and TestChromiumDisplayApplyWhileStoppedNekoRejection drive the real handlers against a fake Neko and a fake xrandr: a 422 becomes a 400 and a 500 stays a 500.
  • Both handler tests fail without the change. go test -race passes for every non-e2e package except TestUpstreamManagerDetectsChromiumAndRestart (devtoolsproxy, untouched). It failed once on a temp-dir cleanup race and passed when rerun.
• Production browser (throwaway session, hot-patched binary): built from the deployed release source plus this change, together with the neko fix. PATCH /browsers/{id} to 63x400 returned 400 viewport_configuration_failed / the display cannot be set to 63x400 at 60 Hz in 0.2s. Before, it returned 500 failed to update session.

Notes

• Overlap with Restart Chromium when a headful display change only changes the refresh rate #497: both PRs touch display.go, in separate hunks. This branch merges cleanly with Restart Chromium when a headful display change only changes the refresh rate #497 as it stands.
• kernel-images-private sync: chromiumDisplayApplyWhileStopped calls the fork-only applyXorgDisplayResolution there. The resolution is to keep the fork's badReq handling and add the ErrScreenConfigurationRejected check after it. I built and ran exactly that for the production test.
• Follow-up: bump ghcr.io/kernel/neko/base in both Dockerfiles once Generate screen modes at the exact requested size and refresh rate neko#31 is tagged.

---

Note

Low Risk
Behavior change is limited to HTTP status mapping for an existing Neko 422 path; no auth or data-handling changes.

Overview
When Neko’s screen API returns 422 (X refused the requested mode), callers previously saw 500, which made unsupported viewports look like a broken VM. This PR classifies that case as a client error.

nekoclient.ScreenConfigurationChange now wraps HTTP 422 in ErrScreenConfigurationRejected. Other non-2xx responses are unchanged.

PATCH /display and the Chromium /configure display step (including live configure via patchDisplayLocked) map that sentinel to 400 with the display cannot be set to WxH at R Hz via unsupportedDisplayMessage. All other resize failures still return 500.

Tests cover the Neko client status handling and both API paths (422 → 400, 500 → 500).

^{Reviewed by Cursor Bugbot for commit 1200e1f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[hiroTamada]

reviewed — the change is tight and well tested. nothing blocking, just one fyi and some nits:

Questions

• server/cmd/api/api/chromium_configure.go:296 — on the stop/start path, the display 400 comes back after policies/extensions were already applied (same as the extensions 400 at :277). fine with that, just flagging that a 400 here doesn't mean nothing was applied.

Nits

• server/cmd/api/api/chromium_configure.go:847 — nit: the extensions 400 is prefixed with the step name (extensions: ...); consider display: ... so they match.
• server/lib/nekoclient/client.go:13-16 — nit: "retrying cannot succeed" holds in practice because neko holds a mutex, but 422 also covers RRSetConfigInvalidTime/Failed from XRRSetScreenConfigAndRate. maybe soften to "is not expected to succeed".
• server/lib/nekoclient/client_test.go:20-23 — consider adding a 401 → retry → 422 case. the login handler in both fakes never runs today because the first request goes out with no token.
• server/cmd/api/api/display_test.go:631 — nit: the fake Neko body is hardcoded to "code":422, even for the 500 subtests.
• server/cmd/api/api/display_test.go:669-674,686-690 — nit: the 500 subtests could assert the message still includes Neko's status, which would catch a mapping that's too broad.