diff options
| author | user <user@clank> | 2026-08-13 12:52:55 +0200 |
|---|---|---|
| committer | user <user@clank> | 2026-08-13 12:52:55 +0200 |
| commit | f5712cda26448eff37f00cd3e25852ef37a85eee (patch) | |
| tree | 92d9597f62821a0008b136224294948dcae73f92 /cli/src/core/errors.ts | |
| parent | docs: record the flakiness as fixed, with the measurements (diff) | |
| download | sl0ppi-f5712cda26448eff37f00cd3e25852ef37a85eee.tar.gz sl0ppi-f5712cda26448eff37f00cd3e25852ef37a85eee.tar.xz sl0ppi-f5712cda26448eff37f00cd3e25852ef37a85eee.zip | |
cli: create sessions by attaching, to dodge the phantom-client bug
Reported symptom: a pane titled "MY FOCUS AND:" in a fresh sl0ppi session.
That is zellij's multi-user indicator. A session created with
`attach --create-background` keeps one client in its connected set forever, so
`connected_clients.len() > 1` and every pane frame renders its multi-user form
with one anonymous colour block. sl0ppi created every session that way, so every
sl0ppi session looked like someone else was in it.
Isolated by comparison rather than by reading:
created with attach --create-background marker on the FIRST attach, and every one after
created by an ordinary attach that dies no marker, ever
Ruled out by measurement: not the CLI-action clients (15 actions with no attach
leaves nothing behind), and not the creating client exiting too early (making it
wait for a server ack -- 94ms, server answered -- changed nothing; that
experiment was reverted rather than shipped with a comment claiming a fix it did
not deliver). The client-id change did not cause this either: it only made it
visible, because recycled ids used to hand the phantom's id straight to the next
client that attached.
So: when `sl0ppi` has a terminal it now creates the session by ATTACHING to it
(`--layout X attach --create NAME`) instead of creating it in the background and
attaching second. That is the path with no leak, and it is one process instead
of two. Headless `up` keeps the background path, where no one is looking at a
pane frame.
This is a workaround. The fork bug is recorded in docs/roadmap.md with what has
been ruled out and where to instrument next, and it still affects anyone calling
`zellij attach -b` directly.
Verified on the test box under a real pty: no marker on creation or on any later
attach, both project tabs present, agents still staged
(purpose='agent:main' held=true cmd='pi').
Diffstat (limited to 'cli/src/core/errors.ts')
0 files changed, 0 insertions, 0 deletions
