fix(terminal): chunk oversized input before backpressure - #83
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 36b13a5f54
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| function writeAvailable(pty: PtySession, data: string): string { | ||
| let offset = 0; | ||
| while (offset < data.length) { | ||
| const chunk = data.slice(offset, offset + MAX_TERMINAL_INPUT_WRITE_CHARS); |
There was a problem hiding this comment.
When a large paste places an astral character such as an emoji across a 4,096-code-unit boundary, slice sends its high and low surrogates in separate terminal.input frames. The host converts each frame independently with Buffer.from(data, "utf8") in packages/host-service/src/operations/pty.ts, so both halves become replacement characters and the pasted command or data is corrupted. Adjust the boundary to preserve surrogate pairs or chunk the encoded bytes instead.
Useful? React with 👍 / 👎.
1 participant
What changed
Why
A 33,000-character paste could exceed the live bridge's pending-input window before any write was accepted. The store queued the whole payload, but no write was in flight, so no later drain event existed to retry it and the terminal remained paused.
Impact
Large pastes now enter the existing ordered backpressure path in bounded chunks instead of deadlocking on the first write. Normal terminal input behavior is unchanged.
Validation
pnpm checkpnpm --filter @t4-code/web test— 87 files, 1,259 testspnpm test:tooling— 136 passed, 1 skippedpnpm test:e2e— 32 passedpnpm verify:affectedreached Android after all checks above; Android was environment-blocked because this machine has no JDK 21Native drawer resize and the final 33,000-character installed-app rerun remain explicitly recorded as follow-up proof boundaries.