https://gitlab.synchro.net/main/sbbs/-/commit/6b25576cea616c566831b052
Added Files:
src/doors/syncduke/tests/test_esc_tear.c
Modified Files:
src/doors/syncduke/syncduke_input.c
Log Message:
syncduke: a sequence split across reads is not a lone Escape

The input pump judged the pending lone-ESC timer before reading the socket, so the tail of a split escape sequence lost the race even when it was already queued. The ESC reached the game as the Escape key, the rest of the sequence
as ordinary keys, and whatever the sequence encoded -- F4's graphics-tier cycle, say -- never happened at all.

In Duke that stray Escape opens the in-game menu, where a bare Q reaches the quit confirmation and a bare Space answers it. A player cycling render tiers gets no tier change, then a menu nobody asked for, then a door that exits without ever showing them a prompt they recognize as one.

The disambiguation window is 50ms of wall clock, but it is only sampled when the pump runs and the pump runs once per presented frame. The text tiers frame slowly enough to hold it open routinely -- sextant measures 7 to 30fps, with stalls -- while the image tiers rarely do, which is why this reads as a sextant-only fault. A single 256-byte read also splits a sequence outright whenever the any-motion mouse reports fill the buffer ahead of it.

Read until the terminal has nothing left, bounded so a flooding client cannot stall the frame, and resolve a pending ESC only afterwards. A genuinely lone Escape still arrives on the first pump past the deadline, which is the case
the timer exists for: SyncTERM sends a bare 0x1b for that key.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net