[Lexus2016]

The report

The terminal drops out often and says it is not connected. It happens when I paste a command, or when I start scrolling the content. At some point the terminal freezes and stays unavailable until I reload the browser window.

What was wrong

Three separate places where the client gives up instead of reconnecting. None of them is the thing that drops the socket — they are what turns a dropped socket into a pane that stays dead until F5.

1. Typing into a dead pane was a silent drain.

term.onData(d => { if (entry.ws && entry.ws.readyState === 1) entry.ws.send(...) });

No else. The keystroke vanished — no reconnect, no message, nothing in the console. xterm renders locally, so the pane still looks alive. That is the freeze in the report.

2. Paste and the send line named the problem and did nothing about it.

Both did toast(t('term.paste.notconnected'), true); return; — on the two controls that exist precisely because a pane has gone unresponsive. That toast is the "Terminal is not connected" the reporter sees.

3. Every automatic reconnect path is conditional on a state a half-dead socket does not report.

onclose only runs if a close event ever arrives; visibilitychange only fires on a tab switch; the backoff can be 30 s out; and entry.exited latches the retry off for good. The only unconditional path was the 🔄 button.

What this changes

_reviveTerminal(sessionId, frame) makes any interaction a reconnect trigger and carries the frame through, so the first thing you type is not the thing that gets lost.

• Only the last frame is queued — a queue of stale keystrokes replayed into a TUI is worse than a dropped one.
• A socket already CONNECTING is not raced with a second one; it delivers the queued frame from its own onopen.
• _pending is cleared before the send, so a failing send cannot replay it on the next open too.
• The exited latch is cleared, for the same reason refreshTerminalSession() clears it: the user asking outranks the latch.

Diagnosis that did not exist

ws.onclose took no argument — the close code was discarded — and the terminal socket had no onerror at all (the chat socket has had one since it was written). A terminal failure therefore left no trace on either end, which is why "it freezes sometimes" was never explained. Both exist now. The log sits after the staleness guard, because a superseded socket closing is routine and would bury the closes that mean something.

Next occurrence will say which it was: 1006 abnormal close with no FIN, 1009 frame over maxPayload, 1011 server error.

What this does NOT fix

What drops the socket in the first place is still unidentified. This PR fixes what the UI does about it. The close code added here is what will name the cause.

One hypothesis was checked and is wrong: a missing server-side ws.on('error') on the terminal socket. It is there, at the top of the wssTerm connection block — it just sits above both sub-blocks, which is why it does not appear near either handler.

Verification

npm test → exit 0. test/composer-terminal.test.js gains 13 checks and had to be repinned twice: it caught the staleness guard being displaced by a log line, and the send-line behaviour changing. That is exactly what it was written for, and both are now pinned in their new form — including the negative pin that the dead-socket refusal is gone.