fix(server-s3): list a member's tmux panes asynchronously

A frozen member (SIGSTOPped tmux server) cost every user one synchronous
3 s block of the event loop per minute (F37's back-off ceiling). Member
listing now runs through async execFile (same 3 s / SIGKILL / 1 MiB
bounds, same back-off) into the listed cache the synchronous readers
(liveSessions, listSessions, listOutput) already use: stale-while-
revalidate, 15 s max age, cold or failing = that member's panes UNKNOWN
(F38 unchanged). A session this process creates or kills is written into
the member's cached answer at once, and a list in flight across that
change is dropped. Host tmux calls, local mode and every click's call
(new-session, send-keys, kill, has-session) are unchanged.

review5's stalled-member test now polls for 4 s past the timeout and
asserts each poll < 100 ms, event-loop stall < 500 ms and one sudo
(old code: first poll 3157 ms).
This commit is contained in:
2026-10-09 15:21:31 +07:00
parent 84e2a9f0ac
commit 4407b3bb16
5 changed files with 206 additions and 57 deletions
+7 -1
View File
@@ -567,7 +567,13 @@ a pane really is. Each case below is refused or bounded, with a test in
- **A member's stopped or flooding tmux server.** Every call on it has a 3 s
limit and a 1 MiB answer cap; one that hit either is not asked again for a
minute. Meanwhile only that member's panes count as unknown (kept, not
ended); everyone else's are still checked. Every other synchronous call
ended); everyone else's are still checked. Listing a member's panes (every
poll: the pane list, the workspace list, the 10 s heal beat, the liveness
reaper) never waits for them: it runs in the background and the poll reads
its last answer, so a stopped server stalls nobody. Until a first answer,
or once the last is 15 s old, their panes count as unknown too. A call a
click makes on a member's pane (start, type, stop) still waits, up to the
3 s. Every other synchronous call
that runs as a member (git in their folder, `write-as`) stops after 5 s.
- **A member's huge or sparse files.** Transcripts and journals are read line
by line with a 64 MiB cap per line (a 512 MB line used to crash the server);