runtime: pi TUI Enter (CR) keypress does not submit under perry — raw-stdin/Kitty keypress decode divergence (real pi interactive blocker)

[proggeramlug]

The ACTUAL blocker for pi's interactive TUI under perry (supersedes the async-generator theory — see below). Pi renders and accepts typed text, but pressing Enter (CR 0x0d) does not submit the message under perry, where node (same bundle) submits and renders the response.

Evidence (fixed-binary A/B, decisive)

Using /tmp/pi-fixed = pi compiled WITH the async-generator await-suspension fix (#6727), interactive PTY repro, bogus API key (a valid request 401s — that's the expected visible result):

Enter byte	perry result	node result
CR 0x0d	"hello" stuck in input, no submit, no "Working…", no 401 (19547 B)	submit → "Working…" → "Error: 401 authentication_error" (33338 B)
LF 0x0a	input processed differently (25792 B) but still no 401	—
CRLF 0x0d0a	25792 B, no 401	—

So no Enter variant submits+responds under perry; node does with CR. The async-generator fix (#6727) does NOT change this (perry CR result byte-identical with and without it) — confirming the keypress→submit path, not async-generator event forwarding, is what blocks pi. (#6727 fixes a real, separate async-generator await-on-pending-Promise deadlock and is worth landing on its own; it would be the NEXT blocker once submit works.)

Mechanism (where to look)

Pi reads raw stdin itself: process.stdin.setRawMode(true) (bundle ~232037) + process.stdin.on("data", stdinDataHandler) (~232095), and runs a custom keypress parser that also negotiates the Kitty keyboard protocol (queryAndEnableKittyProtocol, KITTY_KEYBOARD_PROTOCOL_QUERY). Enter/CR decoding flows through that raw-byte parse (charCodeAt, string/Buffer handling, CR/LF/CRLF logic at ~50346, Kitty sequence parsing). A perry divergence in one of: (a) how stdin.on("data") delivers the chunk under raw mode (Buffer vs string, encoding, chunk boundaries), (b) charCodeAt/string comparison in the parser, (c) the Kitty-protocol negotiation buffer handling, or (d) setRawMode/termios not matching node (CR vs LF delivery). The CR-vs-LF asymmetry points at the parser receiving/classifying the Enter byte differently than under node.

Diagnosis approach

Instrument node-vs-perry inside stdinDataHandler / the keypress parser in the UNMINIFIED bundle (pi-target/dist/pi-bundle.mjs): log the exact bytes/keyname the parser receives and classifies for a sent CR under each runtime; find the first divergence. Repro harness: scratchpad/pty_drive.py (PTY_SCRIPT scripted input); fd pre-placed HOME; cwd=pi-target/dist; binary /tmp/pi-fixed (or recompile). Node oracle: node pi-bundle.mjs. Reduce to a minimal fixture (raw-mode stdin + the same parse shape) and fix the perry divergence node-identically.

Blocks pi interactive chat entirely. Peer walls on the pi path: #6704 (render, merged), #6727 (async-gen, worth landing), OAuth/login (source-tweak workaround).

[proggeramlug]

Corrected root cause — NOT keypress decode; it's event-loop timer scheduling

The keypress-decode hypothesis in the issue is refuted (fixtures proved the whole pi-tui input pipeline — raw-mode CR delivery, StdinBuffer, Kitty negotiation, matchesKey, TUI+Editor dispatch → onSubmit — is byte-identical to node under perry). The real divergence is in event-loop timer/render scheduling.

Repro: render_after_submit.ts (scratchpad/fix6728), mirrors pi's render loop

Main loop awaits input (resolved from a stdin 'data' handler), then await a network turn, then requestRender() which throttles via process.nextTick + setTimeout(…,16). On Enter the handler both resolves the loop AND requestRenders ("after-submit").

• node trace: typing render → RESUMED → after-submit render → turn done → after-turn render
• perry trace: RESUMED → typing render → turn done → after-turn render — the after-submit render is DROPPED, and typing-render vs RESUMED order is flipped.

Mechanism

perry fires the 16ms render timer late — after the next input event rather than at ~16ms. So when Enter arrives, the typing render is still pending (renderRequested flag still set), and pi's render-dedup makes the after-submit requestRender() a no-op → the render that would show the response is swallowed. In real pi this is why submit fires (request goes out) but nothing renders.

Decisive isolation (to confirm/fix)

Hypothesis: perry's event loop does not fire timers while blocked on stdin (the pending-timer deadline isn't integrated into the stdin poll). timer_blocked.ts: setTimeout(fire,100) + process.stdin.resume() with no input — node fires at 102ms; confirm whether perry fires or hangs to the 3s guard. If it hangs, the fix is to integrate the next-timer deadline into the stdin/I-O poll wait (kqueue/epoll timeout = next timer), matching node's libuv loop.

Build note

The existing wt-6728 perry hit a staticlib link skew (libperry_stdlib.a macOS 26.5 vs 26.0, pulling from the MAIN checkout — the staticlib-shadow gotcha). Build perry FRESH in a new worktree from current origin/main so runtime+stdlib staticlibs are consistent.

[proggeramlug]

Correction: the timer diagnosis was ALSO wrong — it was a broken-build artifact

The 'event-loop timer fires late' finding in my previous comment was WRONG. It was produced by testing with a perry that had an inconsistent/stale staticlib link (the prior agent ran cargo build --release but NOT the separate staticlib archives — cargo build --release -j2 -p perry-runtime-static -p perry-stdlib-static — so its compiled fixtures misbehaved). On a clean, consistent build, every fixture is node-identical: timers fire on time while blocked on stdin (timer_blocked ~100ms), render_after_submit matches node, keypress→submit is byte-identical through submit (input clears), and #6709's async-gen fix changes nothing for pi.

The confirmed real wall

After Enter under perry (clean build): submit fires, input clears, and the turn fires its fetch (socket to api.anthropic.com:443 reaches ESTABLISHED) — but the fetch's continuation never runs. The process goes IDLE (sleeping ~1-5% CPU, NOT a deadlock/spin). No 'Working…', no 401. -p one-shot mode fetches fine (gate 2a), so it's specific to the INTERACTIVE loop multiplexing stdin+timers+fetch-reactor.

Hypothesis (being tested): perry's idle event-loop wait (parked on stdin) doesn't wake for a native-fetch completion posted from a background reactor → the continuation waits for the next stdin event. Decisive test: send an extra keystroke after submit; if the 401 renders only then, it's confirmed.

Lesson for anyone working this

BUILD CONSISTENCY IS LOAD-BEARING for pi diagnosis: always build the staticlib archives (-p perry-runtime-static -p perry-stdlib-static, -j2 to avoid the stdlib LTO OOM) in the SAME worktree, or you get misleading runtime behavior. A follow-up agent is now on the real wall with a clean build.