usb-debug (hosted): a 335-char InputText overruns the app's message queue (ServerQueueFull), and a client that dies mid-command wedges the single-client slot

[tobyjaguar]

Environment: KeyOS v1.4.0 (eb2c2edb3) hosted simulator, macOS arm64, loopback usb-debug channel (127.0.0.1:7664).

Sequence observed (2026-09-09):

1. A client sent one InputText of 335 characters (670 key events) to the focused app. The app stalled and gui-server logged Could not send OnVSyncMessage: ServerQueueFull roughly 35 times per second from then on (the per-server message queue in the hosted kernel is shallow and inject_key overruns it).
2. The client gave up and closed its socket mid-exchange.
3. From then on every new connection was refused with usb-debug: refusing 127.0.0.1:<port>, the debug channel already has a client; the single-client serve loop still considered the dead socket its client. Only restarting the simulator recovered the channel.

Expected: (a) a large InputText should be paced or chunked inside usb-debug (or rejected with an error) instead of overrunning the app's queue; (b) a client that disconnects mid-command should free the single-client slot so the next client can connect.

Workaround we use: chunk text to about 24 characters with a short pause (works on hardware too, where injection runs at roughly 20 characters per second regardless of chunking), and never leave a client half-connected.

[badicsalex]

Thanks for the report. We will implement the same chunking and rate-limiting.

The queue is 128 messages deep btw, and calls should be blocking on the client side if it's full, while the gui-server churns through them. Apparently it can't keep up.

[tobyjaguar]

Thanks. Two data points that may help locate it:

• On hardware (Passport Prime, KeyOS 1.4.0-beta3) injection runs at roughly 20 characters per second whatever the chunk size we send: 616 chars took 33 s at 12 chars per InputText, 590 chars took 27 s at 24 per command. So the per-character cost is on the device side, not in the USB round trips.
• On the hosted simulator the 335-character burst did not slow the app down, it stalled it for good (the ServerQueueFull log line kept repeating for the rest of the session), which suggests the inject path is not blocking on the full queue but failing and dropping.

Happy to re-test a build with the rate limiting.

[badicsalex]

Thanks! 20 per second is not a lot tbh, we'll need to profile that. Maybe it causes a full screen redraw.

I'll also check if there's something wrong with QueueFull on hosted in general, because what you saw doesn't sound right.